Re: commit 44ec60d to speed up MAPPLY1 via lambda optimization
David Scherfgen via Maxima-discuss <[email protected]>
| Newsgroups | gmane.comp.mathematics.maxima.general |
|---|---|
| Message-ID | <CAMTHLKjLdT1a=yurdQBtHEbSwh3ppH_FatXoKLWomnj9NQ437g@mail.gmail.com> |
I just pushed some commits mostly focusing on reducing memory allocation
("consing"), one of them stops %coerce-float-fun from invoking the compiler.
There have also been lots of bigfloat optimizations, bringing significant
speedups and reduced consing. The full test suite including share tests is
now down from over 70 GB (if I remember correctly) to below 50 GB of
consing.
SBCL, CCL and ABCL now have support for UNSPECIAL. Previously, a variable
once declared special remained so for all files compiled from there on. On
SBCL, accessing special variables is significantly slower than lexical
variables, and this affected many common variable names such as EXP and
VAR. No more!
I waited with these for after the 5.50 release so that there's enough time
for possible bugs to get noticed.
David Scherfgen <[email protected]> schrieb am Mo., 17. Aug. 2026,
13:32:
> Yes, %coerce-float-fun is a different beast. It actually doesn't need any
> compilation at all, since basically it just calls the evaluator. Not much
> to be gained from compiling that call, it's a waste of resources. Fix is in
> the pipeline ...
>
> Michel Talon <[email protected]> schrieb am So., 16. Aug. 2026,
> 13:11:
>
>>
>> Le 15/08/2026 à 19:45, Robert Dodier a écrit :
>>
>> Hey, I just saw commit 44ec60d which avoids calling COERCE on Lisp
>> lambda expressions, which makes a lot of stuff faster, and makes
>> pattern-matching stuff (e.g. ezunits) much, much faster. That is
>> really terrific!
>>
>> It has always bothered me that pattern-matching stuff is (or was, I
>> guess) much slower than built-in simplification, to the extent that it
>> makes me think twice about bringing pattern matching into the picture
>> for the purely practical reason that it slows down everything
>> noticeably, so this optimization is going to be really helpful.
>>
>> We have seen in the past a similar explosion of compilation time (with
>> sbcl which compiles all functions automatically) when using repeatedly
>> coerce-float-fun (precisely there is a big coerce in %coerce-float-fun)
>> from plot.lisp. This is used of course for plotting but also in other
>> numerical stuff in the share directory (hompack, lbfgs, minpack, romberg,
>> cobyla, colnew, etc.). It would be nice to ensure that the same thing you
>> have done for mapply (keeping a copy of the compilation result in a hash
>> table to avoid recompilation) covers all uses of convert with meval, so
>> that all use case are speedied the same way.
>>
>>
>> --
>>
>> Michel Talon
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>
_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss