[Gcl-devel] [axiom] Gcl roadmap

[root]

> Camm wrote:
> Tremendous!  Always useful to find someone familiar with the existing
> code.  And its fantastic to hear about axiom.  I take it there is
> still no date for release?

re: Axiom's release date. Nope. Still no release date.  I do have a
special contract that lets me work on the sources.  I've rebuilt and
enhanced the Makefile tree, built large portions of the system,
documented small portions of the system and experimented with
connections to numeric libraries and literate programming. These
things will probably be part of the released code once it becomes
available. My hope is to clean it up, upload it to sourceforge and
guide/moderate people who want to work on it. Sort of a software
midwife for birthing it out of NAG.

Camm wrote:
>> the system on GCL at the moment and, yes, it is useful. One unique
>> strength of GCL is the ability to use special input (we call them
>> .fn files) to the compiler to generate better code. The most useful
>
>Thank you for pointing this out.  I was unaware of it, and must
>investigate.  

re: .fn files. Look at cmpnew/collectfn.lsp This function collects
and generates .fn files which can be used to improve the generated
code on the second compile of the function. It was heavily used in
Axiom (and was originally added while Bill and I worked on the
Axiom port to AKCL).

>Camm wrote:
>> Either a decompile function equivalent to CMUCL or a code-walker

>I just ran across the disassemble function in cmpnew/cmpmain.lsp.  Has
>anyone had experience with this?

re: decompile metrics.  Actually, I was thinking of the bytes
necessary to generate a function.  CMUCL has a most interesting
decompile function that shows you the actual assembler code that gets
generated. Several iterations of modifying and disassembling a
function will show you what changes give you the smallest code. In
general I used CMUCL's disassemble function to optimize pieces of
Axiom (e.g. fastplus).

I'll look at cmpnew/cmpmain.lsp and the disassemble function there.

> Camm wrote:
> This would be fantastic.  Unfortunately, I don't have much of an idea
> how to implement it.  Is there a "low-impedance", to borrow from your
> site, example or pointer to look at in the cmucl source?

Unfortunately CMUCL seems to have died. Scott Fahlman and his group
did an excellent job on the project. I don't know of a low impedence
way to get into the internals of any large system :-) I'm just 
tenacious and have a high tolerance for making time-wasting blunders.
Eventually I make enough mistakes to know what to do right :-)

> Camm wrote:
> I've seen mpi bindings for gcl discussed, but no source posted,
> alas. I have some degree of experience with MPI using a research
> cluster at work.  I'd discussed the possibility with Dr. Schelter
> before he died, and the consensus was that, while he had been thinking
> about it too, there was no obvious coarse grained parallelism to take
> advantage of in a symbolic lisp system.

re: MPI. I actually wasn't talking about MPI because it has the notion
of message passing implicit in the design. Message passing is very
costly because you have to "box up" (format) the message and "unbox"
(parse) the message at the other end. I'm trying to think of the
problem from a different angle. I'd like to represent the processors
as "executable units" that could be applied to sexprs (closures?). That
way I can create lists or trees or graphs or hypercubes of processors
and apply the data structure of processors to the sexpr. I want to
hide the fact that there is an architecture under a lisp-friendly way
of THINKING about the problem. MPI and similar libraries are
implementation level details and I don't want to go there yet.
Clearly at this point I don't know what I'm talking about but I do
know that I don't want an MPI interface to show thru. How would a
Symbolics lisp machine use many processors without telling the user?
Suppose I hit an error and enter a break loop. Could one of the options
be "close" which would close over the state, clone it and pass it off
to another processor (transparent to me, of course) for later?

In Axiom I have computations which could branch off into several
subpaths. This might happen because one path is true for solutions
less than zero and another path is true for solutions greater than
zero while the zero solution simplifies. So I have 3 different
subproblems and I'd like to pursue them all at once. Furthermore I'd
like to have a "blackboard" process that records all of the known
facts found on any path. And I'd like other processes to suggest
possible simplifications of intermediate results by applying known
identities (looking for trig simplifications by exponential rewrites)
to subsolutions posted to the blackboard.  I'd like it all to happen
without the Axiom user knowing or caring. So every time I hit a branch
point in a computation I want to close over the computation, give it a
name, and launch it on several processors with different assumptions
(x<0, x=0, x>0) and then combine the results during or after the
computation. Lisp closures will let me do that. Blackboard
architectures are not new. None of this would be magic but it will
require support from the underlying lisp. All I'm asking is that the
support look like LISP THINKING, not networking or parallel
programming or some other low level concern. I don't even care if it
is efficient as long as it works. Give me a better way to think about
the problem and I'll write algorithms that are more efficient.

> Camm wrote:
> You must have heard of MOSIX!

Actually, I've never heard of MOSIX but I'll bet google has.
I'll look for it. 

Tim