gcl-devel
[Top][All Lists]
Advanced

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

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


From: Camm Maguire
Subject: Re: [Gcl-devel] [axiom] Gcl roadmap
Date: 24 Sep 2002 17:17:41 -0400

Greetings!  Just thought I'd check again regarding the release of the
axiom source.  It would make a nice gcl testbed in addition to its
many other uses.  Any headway?

Take care,

root <address@hidden> writes:

> > 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
> 
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

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




reply via email to

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