Re: [armedbear-devel] progress on Maxima + ABCL -- light at the end of the tunnel!
On Thu, Jul 30, 2009 at 8:04 PM, Robert Dodier<robert_dodier@yahoo.com> wrote:
--- On Thu, 7/30/09, Erik Huelsmann <ehuels@gmail.com> wrote:
Another question: I'm running these profiles too, of course. On my system rtest_integrate takes forever to run, could that be this is the main cause it takes that long? Should we start profiling only that test set?
Yes, that sounds reasonable. The integration code makes use of the sign-inference code, to which DGR and DLS belong, so maybe it is actually true that they are doing something that is taking a long time.
Well, I found a reason why ABCL may be taking so extremely long: in SPRDET.lisp, there's a top-level special declaration of the variable name X. In ABCL such declarations are retained after file compilation completes (which is allowed by the spec). Hence, after compilation of sprdet.lisp, any reference to a variable with the name X, or creation of a binding thereof, is a special binding. In ABCL, there's a non-trivial difference between evaluation of a special variable versus a local variable. So, renaming the special variable could be a solution, but that would require a change on part of Maxima; I'm thinking about how to revert the side effect at the end of the file compilation. That's a non-trivial change to ABCL. I haven't figured it out yet. Bye, Erik.
Erik, thanks for looking into the problem. --- On Wed, 8/5/09, Erik Huelsmann <ehuels@gmail.com> wrote:
in SPRDET.lisp, there's a top-level special declaration of the variable name X.
In ABCL, there's a non-trivial difference between evaluation of a special variable versus a local variable.
So, renaming the special variable could be a solution, but that would require a change on part of Maxima;
In this case, there is no problem with changing Maxima, e.g. rename X to *X* or just cut out the special declaration (glancing at the code, it seems the declaration may be unnecessary). As you know, Maxima is an archaic program. This business about special X falls under the heading of "general clean-up" to me.
I'm thinking about how to revert the side effect at the end of the file compilation.
Well, there is a (DECLARE-TOP (UNSPECIAL X)) later on. I guess what is needed is an implementation of "unspecial" for ABCL. best Robert Dodier
On Wed, Aug 5, 2009 at 10:40 PM, Robert Dodier<robert_dodier@yahoo.com> wrote:
Erik, thanks for looking into the problem.
--- On Wed, 8/5/09, Erik Huelsmann <ehuels@gmail.com> wrote:
in SPRDET.lisp, there's a top-level special declaration of the variable name X.
In ABCL, there's a non-trivial difference between evaluation of a special variable versus a local variable.
So, renaming the special variable could be a solution, but that would require a change on part of Maxima;
In this case, there is no problem with changing Maxima, e.g. rename X to *X* or just cut out the special declaration (glancing at the code, it seems the declaration may be unnecessary).
As you know, Maxima is an archaic program. This business about special X falls under the heading of "general clean-up" to me.
I'm thinking about how to revert the side effect at the end of the file compilation.
Well, there is a (DECLARE-TOP (UNSPECIAL X)) later on. I guess what is needed is an implementation of "unspecial" for ABCL.
Well, for the purpose of testing the performance impact of being able to declare "unspecial", I hacked into ABCL an UNDEFVAR primitive function and adjusted lmdcls.lisp accordingly. The change takes ABCL from ~3300 seconds to ~ 2020 seconds evaluation time for Maxima's test suite. However, I'm hesitant to provide the functionality as I've re-run the profiler and this is the new output: 35.8 211251 TMS 36.6 216078 TIMESIN 38.3 226175 SIMPTIMES 40.0 236302 GREAT 45.8 270172 KINDP 59.3 349696 MEVAL1 67.9 400737 MEVAL 77.4 456717 DLSF 84.7 499631 DLS 91.2 538251 DGRF 99.0 583971 SIMPLIFYA 100.0 590104 DGR As a conclusion DGR and DLS are still among the hotest spots in the execution. So, I checked the disassembly again (which is how I discovered about X being taken to be special). From the disassembly, I gather that one of the DO variables (L) is taken to be special too. Searching through the Maxima sources I'm not finding where the specialness comes from... It looks to me like - although I agree with you about the archaic nature of it - that Maxima would greatly benefit from (at least with ABCL) specials to be defined more locally: it's more Common Lisp if it does. I'm thinking about not-implementing the make-unspecial, but the spec allows special declarations to be dropped at the end of a file compilation. I'm thinking about implementing that; it would seem to me it's more what users expect and doesn't add a non-standard feature. I suppose that will eliminate the specialness of L in DGR too. What would you say? Bye, Erik.
--- On Thu, 8/6/09, Erik Huelsmann <ehuels@gmail.com> wrote:
Well, for the purpose of testing the performance impact of being able to declare "unspecial", I hacked into ABCL an UNDEFVAR primitive function and adjusted lmdcls.lisp accordingly.
The change takes ABCL from ~3300 seconds to ~ 2020 seconds evaluation time for Maxima's test suite.
Wow, that's great.
It looks to me like - although I agree with you about the archaic nature of it - that Maxima would greatly benefit from (at least with ABCL) specials to be defined more locally: it's more Common Lisp if it does.
Agreed. About unspecial versus dropping specials automatically at the end of file, I don't have a strong preference, but I am leaning towards automatically dropping them. I can't tell if Maxima expects specials to be carried over from one file to the next; some code might be written assuming they are, but some other code might be written assuming they are not. Be that as it may, I'm pretty sure the unspecial declaration works for only a few Lisps (for the others it's just a no-op iirc). I wonder what other Lisps do. Thanks for your help, Robert Dodier
Well, for the purpose of testing the performance impact of being able to declare "unspecial", I hacked into ABCL an UNDEFVAR primitive function and adjusted lmdcls.lisp accordingly.
The change takes ABCL from ~3300 seconds to ~ 2020 seconds evaluation time for Maxima's test suite.
Wow, that's great.
It looks to me like - although I agree with you about the archaic nature of it - that Maxima would greatly benefit from (at least with ABCL) specials to be defined more locally: it's more Common Lisp if it does.
Agreed.
About unspecial versus dropping specials automatically at the end of file, I don't have a strong preference, but I am leaning towards automatically dropping them.
Ok. I tried a different strategy: I've made (in my local copy) "local" special bindings available for direct manipulation, instead of through the functional interface (which does a lookup, every time). The result was somewhat disappointing: without the "unspecial" stuff, it shaves off only 200 seconds (out of 3300); meaning roughly 7% savings. When I apply the "unspecial" patch (also locally), the additional special bindings change doesn't even make a difference (only a few seconds evaluation time difference with the version without).
I can't tell if Maxima expects specials to be carried over from one file to the next; some code might be written assuming they are, but some other code might be written assuming they are not. Be that as it may, I'm pretty sure the unspecial declaration works for only a few Lisps (for the others it's just a no-op iirc).
I wonder what other Lisps do.
So do I, really. In ABCL, it's a fair amount of work to "unbind" a special (reverse established special bindings); it's possible other lisps have less work to do in that respect. Bye, Erik.
Erik, about the special/unspecial stuff, I am inclined to clean up the use of special variables in Maxima anyway. So maybe we'll get the speed-up eventually when X and L and whatever are changed to something sensible. best Robert Dodier
participants (2)
-
Erik Huelsmann -
Robert Dodier