On Tue, Feb 14, 2023 at 12:48:55PM -0500, Camm Maguire wrote:
> Greetings! Great! Do we also agree it is a win in general to incur a
> little more package build time in exchange for a more compact final
> image set for optimal user performance?
Direct answer is yes. However, the issue is somewhat more
complex. One extra thing is debugability. Related is
robustness. To illustrate, in 'src/interp/interp-proclaims.lisp'
we currently have:
#+:GCL
(progn
(eval-when (:execute :compile-toplevel :load-toplevel)
(proclaim '(optimize (safety 1) (debug 3)))))
This was needed because at safety 0 we got essentially
undebugable failures (and at safety 1 failures were gone
with no hint what could be wrong at safety 0).
Another thing is retaining flexibility. Performance-critical
code in FriCAS is dynamicaly loaded. Dynamic loading of
course is bad for perfomance, but is essential to smooth
developement. And most functions are called in indirect
way. I am not sure how much GCL can optimize this.
In principle this should be easy: "just" generate
"corresponding" C code, that is take advantage of
fact that Spad calls need no special Lisp call processing,
note that Lisp types in Spad code can be mapped to C types
and pass type declarations to C.
The point of above is: if the only tradeof is between compile
time and run time, then it makes sense to turn on aggresive
optimization. But I suspect that there are other effects.
For example, extra code in Makefile or limited debugability
are likely to use extra developement time that could be spend
on other things. And for Lisp code generated by Spad compiler
good optimizations are unlikely to require much time.
--
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/20230214220717.bejkgb5db2imud7z%40fricas.math.uni.wroc.pl.
