Comparisons (for example <) in Maxima's ezunits are a lot slower in Maxima 5.42.0 than 5.41.0

Question

For me the runtime of this comparison: 1`g < 2`g seems to be a lot slower in Maxima 5.42.0 (and 5.42.2, 5.43.0, and 5.43.2) than in 5.41.0. (Note that the first run is always slower.)

Was there a change between 5.41.0 and 5.42.0 that could cause this slowdown? Or am I doing something wrong?

Example run times:

Maxima 5.41.0 with SBCL 1.5.7

Maxima 5.41.0 http://maxima.sourceforge.net
using Lisp SBCL 1.5.7
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) showtime:true;
Evaluation took 0.0000 seconds (0.0000 elapsed) using 0 bytes.
(%o1)                                true
(%i2) load(ezunits);
Evaluation took 2.7650 seconds (2.7780 elapsed) using 1046.148 MB.
(%o2)      /usr/local/share/maxima/5.41.0/share/ezunits/ezunits.mac
(%i3) 1`g < 1`g;
Evaluation took 0.0860 seconds (0.0860 elapsed) using 33.078 MB.
(%o3)                                1 < 1
(%i4) 1`g < 1`g;
Evaluation took 0.0040 seconds (0.0040 elapsed) using 511.469 KB.
(%o4)                                1 < 1
(%i5) 1`g < 1`g;
Evaluation took 0.0040 seconds (0.0040 elapsed) using 543.547 KB.
(%o5)                                1 < 1

Maxima 5.42.0 with SBCL 1.5.7

Maxima 5.42.0 http://maxima.sourceforge.net
using Lisp SBCL 1.5.7
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) showtime:true;
Evaluation took 0.0000 seconds (0.0010 elapsed) using 0 bytes.
(%o1)                                true
(%i2) load(ezunits);
Evaluation took 2.6460 seconds (2.6600 elapsed) using 1033.502 MB.
(%o2)      /usr/local/share/maxima/5.42.0/share/ezunits/ezunits.mac
(%i3) 1`g < 2`g;
Evaluation took 1.0400 seconds (1.0400 elapsed) using 434.087 MB.
(%o3)                                1 < 2
(%i4) 1`g < 2`g;
Evaluation took 0.4350 seconds (0.4360 elapsed) using 170.099 MB.
(%o4)                                1 < 2
(%i5) 1`g < 2`g;
Evaluation took 0.4330 seconds (0.4340 elapsed) using 170.119 MB.
(%o5)                                1 < 2

It seems to be irrelevant of the Lisp version.

Maxima 5.42.0 with Clisp 2.49

Maxima 5.42.0 http://maxima.sourceforge.net
using Lisp CLISP 2.49 (2010-07-07)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) showtime:true;
Evaluation took 0.0000 seconds (0.0000 elapsed) using 56 bytes.
(%o1)                                true
(%i2) load(ezunits);
Evaluation took 5.4127 seconds (5.4136 elapsed) using 82.926 MB.
(%o2)      /usr/local/share/maxima/5.42.0/share/ezunits/ezunits.mac
(%i3) 1`g < 2`g;
Evaluation took 1.7984 seconds (1.7984 elapsed) using 53.569 MB.
(%o3)                                1 < 2
(%i4) 1`g < 2`g;
Evaluation took 0.1951 seconds (0.1951 elapsed) using 3.291 MB.
(%o4)                                1 < 2
(%i5) 1`g < 2`g;
Evaluation took 0.1597 seconds (0.1598 elapsed) using 3.291 MB.
(%o5)                                1 < 2

I compile the Maxima and Lisp versions myself in Docker, so I can run it on AWS Lambda, using the following commands:

wget --quiet --output-document sbcl-1.5.7-source.tar.bz2 https://sourceforge.net/projects/sbcl/files/sbcl/1.5.7/sbcl-1.5.7-source.tar.bz2/download \
    && tar --bzip2 -xf sbcl-1.5.7-source.tar.bz2 \
    && cd sbcl-1.5.7 \
    && sh make.sh "clisp" \
    && sh install.sh

wget --quiet --output-document maxima-5.42.0.tar.gz https://sourceforge.net/projects/maxima/files/Maxima-source/5.42.0-source/maxima-5.42.0.tar.gz/download \
    && tar -xzvf maxima-5.42.0.tar.gz \
    && cd maxima-5.42.0 \
    && ./configure --enable-sbcl-exec \
    && make \
    && make install

Update

We've tried looking into the issue ourselves. Unfortunately we're not experienced enough with lisp to find a solution.

What we did find out was that the performance was fine when we used the precompiled version of Maxima 5.43.0 using GCL. That version can be found here: https://sourceforge.net/projects/maxima/files/Maxima-Linux/5.43.0-Linux/

Maxima 5.43.0 with GCL 2.6.12

Maxima 5.43.0 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) showtime:true;
Evaluation took 0.0000 seconds (0.0000 elapsed)
(%o1)                                true
(%i2) load(ezunits);
Evaluation took 0.4100 seconds (0.5600 elapsed)
(%o2)         /usr/share/maxima/5.43.0/share/ezunits/ezunits.mac
(%i3) 1`g < 2`g;
Evaluation took 0.1700 seconds (0.1700 elapsed)
(%o3)                                1 < 2
(%i4) 1`g < 2`g;
Evaluation took 0.0500 seconds (0.0500 elapsed)
(%o4)                                1 < 2

This was also run in a docker container. Maxima was installed using these commands:

wget --quiet https://downloads.sourceforge.net/project/maxima/Maxima-Linux/5.43.0-Linux/maxima-5.43.0-1.x86_64.rpm \
    && wget --quiet https://downloads.sourceforge.net/project/maxima/Maxima-Linux/5.43.0-Linux/maxima-exec-gcl-5.43.0-1.x86_64.rpm \
    && rpm --install --verbose --hash maxima-5.43.0-1.x86_64.rpm maxima-exec-gcl-5.43.0-1.x86_64.rpm

Thanks for the update. Different Lisp implementations carry out the various operations needed with greater or lesser efficiency -- my guess is that the costly operation `ev(ff%, args(known_unit_conversions), infeval)` is making use of some function calls over and over, and that function or functions are more efficiently implemented in GCL than in SBCL. Some tracing and debugging might reveal what they are. However the way to fix this issue for all Lisp implementations is to make it somewhat smarter in ezunits, which I have on my to-do list. — Robert Dodier, Mar 11 '20 at 23:46

score 4 · Accepted Answer · answered Feb 13 '20 at 22:14

Tracing some of the functions involved, it looks like the largest part of the time to process 1 ` g < 2 ` g is spent in dimensions, which is a function to figure out the dimensions (mass, time, length, etc) of units, and in dimensions, most of the time is spent in a expression-matching rule named rff which looks like this:

(%i22) disprule(rff);
(%t22) rff : dimensions(ff%) -> block([ff%2 : 
ev(ff%, args(known_unit_conversions), infeval)], 
if ff%2 # ff% then dimensions(ff%2) else dimensions(ff%))

Here ff% is a symbol such as g. The effect of rff is to convert g to kg/1000, and then some other rules operate on the kg (and the 1000) to find that the dimension is mass.

The ev(ff%, args(known_unit_conversions), infeval) is a simple way to find the fundamental units, but it is relatively slow, as you pointed out, because it brings the whole list of unit conversions into the picture, when only one is really needed. I agree that a more efficient method is desirable, since it would probably speed up operations on units in general. Feel free to submit a bug report (https://sourceforge.net/p/maxima/bugs/) about this.

I didn't look at the commit history so I don't know what changed between versions. Anyway it seems clear where is the bottleneck in the present version.

Thank you for the quick answer! I created a bug report here: https://sourceforge.net/p/maxima/bugs/3609/ — MOUSHerN, Feb 14 '20 at 10:58
I've updated the question. The performance is good for us with Maxima (5.43.0) using GCL (2.6.12). That just makes things more confusing for me. — MOUSHerN, Mar 11 '20 at 16:13

Comparisons (for example <) in Maxima's ezunits are a lot slower in Maxima 5.42.0 than 5.41.0

Update

1 Answers1