On Fri, Dec 4, 2009 at 7:42 PM, Tim Daly <[email protected]> wrote: > Intel has been muttering about putting a whole virtual machine on > each of the 48 nodes. I'm thinking more along the lines of a lisp > kernel per node with shared heap. Clojure is interesting because of > its immutable data structures and refs. Asus systems sells a 384 > node machine that runs a JVM per node and I had previously looked > at that for a Clojure-based Axiom.
The nodes are full x86_64, right? I think you need *some* kind of OS / kernel, although it might well be a "microkernel" along the lines of the Dresden Real-Time Operating System (DROPS) rather than a full Linux or BSD kernel. I don't know if there's a "bare metal JVM" or a hardware implementation of the JVM. Then again, I'm mostly a number cruncher and operating system programmer, so maybe I see a need for an OS simply because I like working on them. ;-) > Intel has asked for research ideas and I submitted this idea. Since > this is open source the best we can hope for would be internet access > to a hardware platform (which might be implemented in ASIC chips for > all we know). I don't know about that - Intel is pretty supportive of open source, at least here in Oregon. ;-) And they used to have a pretty strong HPC team here (Floating Point Systems alumni), although I haven't run into any of them recently. If there is an upstream market for massively parallel symbolic computing, I'm sure they'll give you what you need. > I have been collection parallel constructs and building a set of lisp > tools for each one. For example, take, drop, interleave, curry, zip, > filter, etc. would be primitives for control. Rich Hickey made the > interesting observation that essentially amounts to something like > "Loops considered harmful". As I rewrite the Axiom internals I'm > working on lifting it onto the parallel primitives. > > The real game is to lift the whole parallel idea into the symbolic > context so algorithms can be fully parallel. My view on that is to use > provisos as the basis for fork/join computations under restricted > assumptions for each fork. Of course, a forked computation of > f(x,y) such that x > 0 > could end up forking again under > f(x,y) such that x > 0 & y > 0 > f(x,y) such that x > 0 & y = 0 > f(x,y) such that x > 0 & y < 0 > > Groebner basis computations could be done in parallel with different > orders and terminated when a solution is found (parallel poisoning) I thought there were "massively parallel" Groebner basis solvers already - is that a wheel that needs re-inventing? > Parallel root finders could use a blackboard structure to use the > discovery of one root to reduce the problem for other parallel finders. > > There are a lot of interesting paths to take. Yeah - many of these paths were partially illuminated in the late 1980s - early 1990s and then abandoned. I think, though, this time around, there's massive commitment to parallel / concurrent programming from big players like IBM, Intel, Microsoft and Google. Oracle too, probably. ;-) -- M. Edward (Ed) Borasky http://borasky-research.net "I've always regarded nature as the clothing of God." ~Alan Hovhaness _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
