[Gcl-devel] Re: [axiom] Gcl roadmap

[Camm Maguire]

Greetings!

root <address@hidden> writes:

> Camm,
>  
> You wrote
> 
> 
> > Any feedback on the above is much appreciated.  In addition, I'd like
> > some frank feedback on the following:
> 
> > 11) Is gcl useful?  Does it still provide something which isn't
> >     readily available in other systems?  I.e., frankly, is there a
> >     need or even desire for gcl to continue?  Developing the system is
> >     interesting, and even somewhat enjoyable, but it seems like a
> >     waste of effort if everyone would rather use something else.  If
> >     there are unique strengths of gcl, what are they?  What should we
> >     concentrate on to truly provide a needed service for users, rather
> >     than trying to simply catch-up to what is available somewhere
> >     else?   Please don't get me wrong -- I don't mind working on gcl
> >     at all, but I do want to be effective.
> 
> I worked with Bill Schelter on AKCL centuries ago and we used AKCL
> as the basis for Axiom, a large computer algebra system. Axiom is
> in the process of becoming open source as you can see on the temp
> website: home.earthlink.net/~jgg964/axiom.html
> 

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?


> One of the major supported lisp platforms will be GCL. I'm building
> 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.  

> thing for Axiom would be an way to measure the generated code size.

In terms of .text and .data size in bytes?  That would be easy
enough. 

> 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?

> that could recommend code-reduction techniques (e.g. we use a
> macros like fastplus which generates something like:
> 
> (the fixnum (+ (the fixnum x) (the fixnum y)))
> 
> which in CMUCL generates 1 instruction in some cases. 

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?

> 
> A second useful facility would be to think about spreading the lisp
> image across multiple machine transparently. We're moving to a

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.

> beowulf cluster and the clustering issues are being debated. I'd
> like to see Lisp able to create closure objects and pass them
> around as "task boxes" transparently. What would lisp be like if
> we hide the multiple memory images on multiple machines and
> reflect it as one big heap? What parts of the kernel are needed

My guess is that this approach would suffer from the same limitations
as distributed memory approaches to parallel computing -- namely the
requirement of very costly, low-latency high-bandwidth networks.  The
key to the low end cluster, IMHO, is identifying a natural coarse
grain for the parallelism, and the heap operations appear to be very
fine. 

> to run on the slave machines if the master machine is the only
> one with console I/O? How would a multiple-memory garbage collector

Indeed :-)!

> work? Imagine a split heap, stop and copy GC that instead used an
> N-way heap with stop and copy from one node to another. Or suppose
> your "static area" is really the memory of another machine that
> serves numeric library results transparently. Loading a routine

Now this is more achievable, I'd think.

> locally would actually construct the call to a slave node and
> wrap the funcalls with trampoline code to execute the function
> on a slave node. Nodes could be reflected as lists of processes
> that can be pushed, popped and applied to sexpressions. List conses

You must have heard of MOSIX!

> could cross node boundaries, etc. CMUCL has "wires" which is a
> networking notion but not a unified image.
> 

Fascinating proposals!  Anyone have any prototypes/initial attempts
working in the Lisp world?

Take care,

> Tim Daly
> address@hidden
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah