axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Re: Some code, if you are interested.


From: root
Subject: Re: [Axiom-developer] Re: Some code, if you are interested.
Date: Mon, 6 Oct 2008 02:44:07 -0400

>> Have you looked at clojure? I was very skeptical of this lisp-on-jvm
>> but he makes some very good points about scaling on multiple processors.
>> I think this topic will become important in future CAS systems and he
>> seems to have spent a good deal of time on that subject. I strongly
>> recommend reviewing the clojure for lisp videos by Bill Hickey. I think
>> he has some fundamentally useful ideas for exploiting parallelism which
>> could be reflected into Axiom.
>
>I remember reading in the Axiom literature somewhere that Axiom was
>designed so it could be ported to different Lisp implementations with
>a reasonable amount of effort.  What are your thoughts on the
>possibility of enabling Axiom to run on Clojure?

I spent a few hours watching Hickey's videos and some time exploring
his immutable data structures. I have downloaded but not yet run clojure.

The key interesting idea of Clojure is that the system scales well
when given multiple cores. I feel this is important in the long term
for Axiom.

I can see several possible paths of interest. 

First, some areas of future planned coverage for Axiom include 
areas where algorithms do not exist, only procedures which are not
guaranteed to terminate. This occurs in my other project (Magnus)
which involves the area of infinite group theory. In that project
the user interface allows several procedures to compete for CPU
time and, if one succeeds, to poison the others. This scales well
for multicore machines. Moving those procedures into Axiom is
blocked on the multi-thread issue so far.

Second, there are "embarassingly parallel" tasks such as matrix
multiplication that can give scaling within algorithms.

Third, there are multi-branch algorithms in an area called Provisos
where I've done a lot of research. The basic idea is that you decorate
each intermediate expression with "such that" conditions, which I term
"provisos". For instance 1/x provided x != 0. At each step of the
computation additional provisos might get added. My research approach
to this uses symbolic intervals so that
   1/x provided x != 0
becomes
   1/x for x in [-oo..0)
   1/x for x in [0..0]
   1/x for x in (0..+oo]
which then becomes 3 independent computations. Each new intervaled
proviso continues to fork into independent computations. As answers
are reached the proviso forks are rejoined based on their intervals
of validity. In general, this leads to natural parallelism. Since
Clojure has immutable data structures the intermediate results can
be naturally shared.

Probabilistic algorithms is another area where parallelism can be
exploited.

Finally, within Axiom, in the 30 year horizon plan is the crystal
interface which presents multiple, connected facets that are 
dependent views of the same problem (one facet has documentation;
another source code; a third, the running state; a fourth, the
related internet papers, etc.) Each facet is maintained on a separate
process/processor working off a common knowledge network data structure.



Given those thoughts I'm interested in Clojure. While I'm very skeptical
of "another lisp" in general it seems that Hickey has tried to stay close
to the common lisp language where practical.

Clojure raises a few questions. What is the expected Lisp API that
Axiom requires? I know Axiom uses tail recursion which Clojure does
not yet have but there is some promise that something is "in the pipe".
And Clojure provides the recur mechanism.

How would the parallel nature be exported from the lisp upward into Spad?

Is the performance hit for normal programs too great relative to the
performance gain on parallel work?

Can I just implement Hickey's immutable structures and get the same
benefit?




As you can see I'm in the process of writing down the details of the
system internals, including some rewrites of the compiler/interpreter
code into common lisp. I hope to find time to play with Clojure enough
to be able to architect the ideas cleanly into the reorganization.

Tim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]