On Sun, Jul 03, 2022 at 06:38:22PM +0800, Qian Yun wrote:
> I find the idea of pure lisp build of FriCAS very interesting and
> useful. I did some improvement of Kurt's fricas0 at
> https://github.com/oldk1331/fricas0
>
> The biggest advantage is that you can start FriCAS quickly and
> do computation right away.
>
> No need to spend 1.5 minutes (this is parallel build, single core
> can take 6 minutes) to compile FriCAS from source before doing
> computation.
>
> fricas0 comes with lisp files pre-compiled from spad files.
>
> Another improvement I did is to allow "load on demand" or
> "compile on demand".
>
> If you want to do some (simple) computation like "1+1",
> there is no need to compile all lisp files to do that.
> You can load the needed algebra lisp files on demand.
>
> Of course, the load (aka interpreting) can be slow. If your
> computation is not that simple, you can compile the needed
> lisp files before loading.
>
> I find that sbcl has very slow interpreting speed for unknown reason.
What we use is called by sbcl folks "old interpreter". There
is also new interpreter which is supposed to be much faster.
Historically, early sbcl compiled everything, "interpreter"
compiled on the fly. Later sbcl folks added true interpreter.
Early in FriCAS developement it turned out that FriCAS passed
a lot of expression to Lisp 'eval' and compiling them (which was
sbcl default) took substantial time. So in 'fricas-lisp.lisp'
we have:
(setf sb-ext:*evaluator-mode* :interpret)
This gave subtantial speedup. Some time ago it tunrned out
that this setting is incompatible with using new sbcl interpreter.
So you may wish to experiment with this new interpreter
(which was configured (and probably still is) at sbcl
build time) removing or changing setting above.
> ECL calls gcc to do compilation, so it is a bit slow.
> I find that CLISP has good loading speed, relatively good compiling
> speed, not good but good enough execution speed.
Hmm, if you wish ECL compiles to bytecode. Compilation
to bytecode is quite fast and interpretation of byte code
also is reasonably fast. IIRC ECL bytecode runs faster
than "compiled" CLISP.
Similarly GCL has fast interpreter (but I do not know if
it has any advantage over ECL).
Also, Clozure CL compiles much faster than sbcl.
One may also look at old Codemist CLL build. With CCL
vast majority of algebra was interpreted, but few selected
parts were compiled to C for speed (for this CCL has special
Lisp to C compiler). While trying to resurect CCL probably
is not worth the effort similar idea could save compile
time with other Lisp-s: identify speed-critical files and
compile them, interpret the rest. CCL list of compiled
files may be a start (but probably there are more critical
files now).
> This can have great speed up for using git-bisect to find regression.
>
> I have compiled all 131 versions from 1.3.7 to current git HEAD,
> and put them into a separate git repo. It takes surprisingly small
> amount of storage -- .git is only 16 MB.
> git-bisect will need at most 10 runs to find the faulty commit.
>
> So if a test takes 20 seconds (compile time and execution time) to run,
> we can find the faulty commit in under 200 seconds.
>
> For example, the pattern-match integration regression, I have the
> following test script:
>
> ====test.sh
> rm algebra/*fas
> echo -e
> "f:=integrate((F^((-a*x+1)^(1/2)/(a*x+1)^(1/2)))^n/(-a^2*x^2+1),x)\nis?(operator
> mainKernel f,'integral)\n)quit\n" | clisp fricas.lisp | grep false
> ====
>
> git bisect start; git bisect bad; git checkout HEAD~130; git bisect good
> time git bisect run ./test.sh
>
> This gives correct result (c8ef0784485f8106bccbc7c8ecb63be485ec654e)
> in 145 seconds.
Nice.
> I have published this (sample/beta) fricas0-repo at
> https://github.com/oldk1331/fricas0-repo
>
> == Further optimizations
>
> Current fricas0 runs in single thread. If we run a test once, we then
> know which files it uses. Then we can compile them in parallel in
> advance for following bisect runs. This should improve git-bisect speed
> by a few times more on multi-core machines.
>
> (In the above example, compile time is 12s and execution time is 8s.
> So with parallel complication we can get total time from 20s to 10s.)
>
> I think the format of *.daase and *.text can be improved. Some of the
> KAF optimization doesn't make sense anymore. Small changes in code
> should not cause huge changes in them.
I am not sure what you mean. Small changes in source code may
lead to large change in object code (but usually change to
object code is also small), this is nature of compilation.
--
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/20220703124235.GA16335%40fricas.math.uni.wroc.pl.
