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

"Much of Maxima's internals depend heavily on serialization, as they
use global variables etc."

Can you consider rewriting these internals.

All of this is academic, since Lisp does not use multi-core properly.  I don't know if that is going to change soon.


 ------------Original Message------------
From: "Richard Hennessy"<rvh2007 at comcast.net>
To: "Stavros Macrakis" <macrakis at alum.mit.edu>
Cc: "Maxima List" <maxima at math.utexas.edu>
Date: Fri, Jul-18-2008 10:59 PM
Subject: Re: [Maxima] "fastfib" in the gf package faster than "fib"

"you run into the problem of keeping things like the "assume"
database separate for different execution paths."

You guys use cvs for version control.  I have used Microsoft SourceSafe.  You can just store the information needed to reconstruct the source instead of making copies on top of copies and more copies of the source.  That is how SourceSafe works.  I don't know about cvs.  This idea works for the assume database.  You don't have to maintain more that one copy, just use an assume data structure like a tree instead of an assume "database" structure.  I am not sure if this is too much overhead for multithreading to be better.  It may be a good idea anyway in spite of the overhead of a more complicated assume data reconstruction process.  A compromise might be better here.  In any case you would have to redo the way assume works internally.  This could require reengineering the whole thing.  Oh, well.


 ------------Original Message------------
From: "Richard Hennessy"<rvh2007 at comcast.net>
To: "Stavros Macrakis" <macrakis at alum.mit.edu>
Cc: "Maxima List" <maxima at math.utexas.edu>
Date: Fri, Jul-18-2008 10:00 PM
Subject: Re: [Maxima] "fastfib" in the gf package faster than "fib"

"It's not clear where we could actually get some useful results with
a reasonable amount of programming.  But of course if you have ideas,
dive in!"

Most divide and conquer algorithms would be good to run in separate threads.  I don't know the insides of Maxima but divide and conquer algorithms are very common in computer science and maybe also inside Maxima.  Another place to start, maybe?

Rich



 ------------Original Message------------
From: "Richard Hennessy"<rvh2007 at comcast.net>
To: "Stavros Macrakis" <macrakis at alum.mit.edu>
Cc: "Maxima List" <maxima at math.utexas.edu>
Date: Fri, Jul-18-2008 9:38 PM
Subject: Re: [Maxima] "fastfib" in the gf package faster than "fib"

"It's not clear where we could actually get some useful results with
a reasonable amount of programming.  But of course if you have ideas,
dive in!"

It would be nice if operators and functions "thread" over lists.  Mathematica I think does this, at least they claim to without defining "thread over a list".  I think they mean one thread is created for each element in the list.  That would be a nice place to start with just a little programming and lots of gains.

"I don't know if there are good debugging tools for parallel Lisp code...."

Just use assertions, that is good enough generally, I rarely use debuggers personally but they are nice for some really nasty bugs.  The kind you get when you are inexperienced in a new language, well in that case debuggers don't help much anyway.

Rich


 ------------Original Message------------
From: "Stavros Macrakis" <macrakis at alum.mit.edu>
To: "Richard Hennessy" <rvh2007 at comcast.net>
Cc: "Maxima List" <maxima at math.utexas.edu>
Date: Tue, Jul-8-2008 6:10 PM
Subject: Re: [Maxima] "fastfib" in the gf package faster than "fib"

On Tue, Jul 8, 2008 at 3:59 PM, Richard Hennessy <rvh2007 at comcast.net> 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?

It would certainly be nice to get an almost 2x speed improvement, but...

* I don't think any of our usual Lisps (GCL, CMUCL, CLISP, etc.)
support multiprocessor threads. The biggest challenge there is garbage
collection, though they probably have other global structures
internally that would pose difficulties.
* Common Lisp as far as I know has no standard interface to threads,
so that means portability would be a problem.
* Many parts of the system would probably not benefit at all.
* It's not clear where we could actually get some useful results with
a reasonable amount of programming.  But of course if you have ideas,
dive in!
* Much of Maxima's internals depend heavily on serialization, as they
use global variables etc.  Even if you want to parallelize at a high
level, you run into the problem of keeping things like the "assume"
database separate for different execution paths. Then again, some
kinds of calculations could take advantage of parallelization at the
process level, obviating the need for mucking around with Maxima
internals.
* I don't know if there are good debugging tools for parallel Lisp code....
* For nicely modular calculations which run for a long time, these can
be run in separate processes which can do whatever they like,
including cloud computing (run your calculation on a hundred virtual
machines at Amazon!).

In any case, I'm not quite sure what exactly your project is and how
we can help!  Presumably it's something more interesting than a screen
saver....

           -s


_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima


_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima


_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima