On Sun, Oct 15, 2023 at 10:38:26PM +0800, Qian Yun wrote:
> While testing my memory usage report patch, I found that loop in SBCL
> is much slower than other Lisps and takes much more (20x) RAM!
>
> [x for x in 1..5*10^5];
>
> For SBCL, it takes 1.75s and 668MB;
> For ECL, it takes 0.34s and 36MB;
> For CCL, it takes 0.11s and 20MB;
> For CLISP,it takes 4.87s and 340MB.
>
> Not only that,
> ")lisp (progn (loop for x from 1 to 5000000 collect x) 1)"
> is also slow in FriCAS, but fast in SBCL.
>
> After some debugging, I found that
> (setf sb-ext:*evaluator-mode* :interpret)
> in src/lisp/fricas-lisp.lisp is responsible.
>
> Quoting Waldek from "Re: sbcl: 971 Segmentation Fault" in 2007:
>
> ````
> You may delete this line -- this line just tries to optimize build
> speed. Namely, Axiom during Spad compilation makes heavy use of eval.
> Profiling indicated that more than 10% of time is spent compiling
> Lisp forms passed to eval. The line above switches sbcl
> evaluator to use true interpretation, which significantly
> reduced time used by eval. However, sbcl got interpreted evaluation
> somwhere late within 0.9 series.
> ````
>
> So it was an optimization for building. I did following test (make -j8):
>
> Build FriCAS by default : 3m26.863s, test (-j1) takes 1m1.040s
> Build FriCAS without :interpret: 3m23.284s, test (-j1) takes 1m14.889s
> Build FriCAS with sb-fasteval: 3m19.433s, test (-j1) takes 1m1.311s
>
> So nowadays this option does not affect build time at all. (It does
> affect test running a bit though. Not look into it yet.)
>
> After removing this setting, the loop is fast now: 0.11s and 21MB.
>
> So shall we do this change?
Well, I noticed the issue tooking at build time, but this is really
general problem:
- sbcl compiler is slow (takes a lot of time to generate code)
- default sbcl interpreter is slow too
Most things that we pass to sbcl eval is trivial, so slow interpreter
is still significantly faster than compilation+compiled runtime.
Note that if you put your loop in a function, it will be compiled
and run at compiled speed. I feel that such loops on command
line are rare enough that our current setting is better than sbcl
default.
Concerning build time: using interpreted eval gave us significant
speedup, but not using eval is faster, so a lot of evals in compiler
are removed (replaced by different code). But for handling
code generated by FriCAS interpreter use of eval is currently
unavoidable...
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZSwC8I1QC5n7AsVS%40fricas.org.
