Re: [Axiom-developer] Intell SCC chip, Clojure, and Provisos

[M. Edward (Ed) Borasky]

On Fri, Dec 4, 2009 at 7:42 PM, Tim Daly <address@hidden> 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