"fastfib" in the gf package faster than "fib"

As does ECL and CMUCL.

That is an interesting thought, SBCL could create new threads during its
built in functions.  That could make SBCL automatically faster on SMP
processors (and of course introduce concurrency problems).  However, in my
experience with SBCL, I have not seen it create threads without me asking it
to.  It seems that any multithreading is left up to the user (and the
systems he/she installs).  However, I have seen this kind of talk of
detecting parallelizable code on the sbcl-devel mailing list.

Slime (a common lisp development environment) is somewhat smart about
threads, and will create a new thread for each command you send to it (so it
doesn't tie up input for the user).  This might be achievable for someone
who wants to dig into the slime internals, but it would still not give you
the 100% CPU usage you want.

Zach


On Tue, Jul 8, 2008 at 2:46 PM, Raymond Toy (RT/EUS) <
raymond.toy at ericsson.com> wrote:

> Richard Hennessy wrote:
> > Any chance of Maxima or some Lisp implementations soon being able to use
> core duo correctly (e.g. multi-threading)?  My PC has 2 cores and Maxima
> never uses more than %50 of the available CPU time.  I have written screen
> savers that use %100 percent but who cares about that.  I don't use them.
>  Why fry my CPU?
>
> SBCL supports threads.  I think openmcl does too.  Maxima doesn't use
> any threads so I don't know what benefit you might see, if any.
>
> Ray
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>