On Sun, Jul 03, 2022 at 09:48:04PM +0800, Qian Yun wrote:
>
>
> 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?
Really nothing to add to what I wrote:
(setf sb-ext:*evaluator-mode* :interpret)
gave error when sbcl was configured with sb-fasteval. I seems
that sbcl folks fixed this.
> >>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.
Hmm, so with bytecode compiler it is slower than with compile
to C? Strange.
> >>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?
interp.daase and operations.daase is really object code. They
are used by interpreter and Spad compiler. Anyway, IMO changes
to interp.daase after source change are justified: we have an
index and since positions changed there are changes in index.
Index means that there is no need to load whole interp.daase
which saves startup time and memory use. The savings are not
big but IMO worth to have.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20220703172557.GA21480%40fricas.math.uni.wroc.pl.
