On 7/3/22 20:42, Waldek Hebisch wrote:
What we use is called by sbcl folks "old interpreter". There
is also new interpreter which is supposed to be much faster.
Yes, that is sb-fasteval documented in sbcl/src/interpreter/README.
You are right, this new interpreter is blazing fast when loading
the fricas.lisp (SPAD interp directory)!
For the same integral, sb-fasteval takes 12.5 seconds, sbcl copmile+run
takes 26 seconds, clisp compile+run takes 20 seconds.
Some time ago it tunrned out
that this setting is incompatible with using new sbcl interpreter.
More info?
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.
Yes, this new interpreter requires configure at sbcl build time.
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.
ECL bytecode is enabled by (ext:install-bytecodes-compiler).
ECL bytecode compile+run time is 38.5 seconds.
The default C compile+run time is 25 seconds.
Similarly GCL has fast interpreter (but I do not know if
it has any advantage over ECL).
I do not test GCL, because GCL-2.6.12 has issues on my platform
and FriCAS does not support newer 2.6.13-pre releases.
Also, Clozure CL compiles much faster than sbcl.
ClozureCL compile+run takes 9 seconds. (It takes another 9 seconds
loading (actually compiling) fricas.lisp (SPAD interp directory),
but that can be optimized.)
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).
Yes, with some profiling and some experience, we can selectively
compile some files and interpret the rest, to achieve the smallest
compile+run time.
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.
Now the sbcl fasteval takes 95 seconds.
And ClozureCL takes 117 seconds.
ClozureCL can be faster because it spent almost half of the time
compiling src/interp.
I think we can exclude loading of unneeded part, like hyperdoc
interface, and SPAD compiler, etc.
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.
I'm not talking about object code, I'm saying that some small changes
in SPAD file can result in thousands lines of changes in *daase and
*text. They have some "Keyed Access File" optimization, right?
- Qian
--
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/0190a53c-ae3f-0698-a20b-509d31f728a9%40gmail.com.
