Subject: Initial- and boundary-value problems in Maxima.
From: Raymond Toy
Date: Thu, 15 Sep 2011 15:51:49 -0700
On Thu, Sep 15, 2011 at 3:29 PM, Richard Fateman
<fateman at eecs.berkeley.edu>wrote:
> On 9/15/2011 3:18 PM, talon at lpthe.jussieu.fr wrote:
> ...
>
>
> This being said the total cost of garbage collection, 2s is negligible
>> with respect to the 60s, but not to the total running time of the fortran
>> version (< 1 s).
>>
>
> The cost for gc may not be high, but the fact that it is needed at all
> suggests that something is going on that is not necessary. The fortran
> program presumably just uses the arrays that it is given as arguments, so
> there should be no array allocation. I think it is just creating
> floating-point number "boxes".
>
Don't have an explanation for all of this, but certainly daxpy needs
consing. Or rather the caller must do it because it needs to pass a
double-float value to daxpy. There are also some known issues in cmucl
that some consing happens when it seem that it shouldn't. I'll have to
compile the code at higher optimization to see all of the boxing notes to
see if they make sense.
>
> I don't understand the discrepancy between 50% of the time and "negligible"
> between Michel and Ray;
> since I have some interest (as does Ray) in making lisp numerical programs
> run fast, I hope we can come to some agreement on this.
>
> Could be that sbcl did a better job of optimizing, especially if it's a
64-bit version because then the 32-bit integer Fortran quantities will fit
nicely in a fixnum. Could also be a bug in cmucl's profiler.
Ray