[Gcl-devel] Re: Common Lisp Implementations: A Survey

[Camm Maguire]

Greetings!

Daniel Weinreb <address@hidden> writes:

> Camm,
> 
> Hi. There are a few things in your answer that I'd appreciate
> some clarification on, since I don't understand them:
> 

Of course, no problem.  Please feel free to enquire further if the
below does not suffice.

> Camm Maguire wrote:
> > The following message is a courtesy copy of an article
> > that has been posted to comp.lang.lisp as well.
> >
> > Greetings!  Sorry about the delay here.
> >
> > Good luck with your project.
> >
> > Daniel Weinreb <address@hidden> writes:
> >
> >   
> >
> > GCL
> >
> >   
> >> What's the current version number?
> >>
> >>     
> >
> > 2.6.7, 2.6.8pre in Debian at the moment in 2.6.7 guise.
> >   
> I don't understand what you mean here.

cvs tag "Version_2_6_8pre" (aka 2.6.8pre) is the next stable release
candidate.  This is tested via uploading into Debian unstable as a
"package patch" against the released 2.6.7 sources.  So right now we
have 2.6.7-36 in Debian unstable, which is the same as the current
2.6.8pre sources in cvs.  When finalized, we will do a non-branch tag,
and rename the sources to 2.6.8.

> >   
> >> Name of institution (company, etc) responsible for maintaining this
> >> implementation, if any.
> >>
> >>     
> >
> > volunteers across the world
> >
> >   
> >> Could you say something about how many developers are actively working
> >> on maintenance and development of this implementation?
> >>
> >>     
> >
> > GCL development, like many open source projects, proceeds in bursts.
> > At such times, contributors number from 5 to 10.
> >
> >   
> >> What platforms does it run under?  By a platform, I mean
> >> a pair of < operating system, hardware archictecture >,
> >> such as MacOS/PowerPC, Linux/Intel-64, etc.
> >>     
> >
> > macosx, windows (mingw), solaris (sparc and intel), all 12 Debian
> > Linux platforms
> >   
> What hardware architectures are supported for MacOS?
> 

At the moment powrepc only.

> What does "mingw" mean?
> 

"Minimum GNU environment" or some such.  Windows users seem to prefer
this to cygwin as it is closer to native windows.  mingw provides a
gcc port, etc.

> I don't know what the 12 Debian Linux platforms are.

i386 amd64 sparc s390 alpha ia64 hppa m68k arm(armel) ppc mips mipsel.

> > macosx/intel still needs finalization
> >
> >   
> >> What is the availability of the source code?
> >>
> >>     
> >
> > LGPL,GPL (some modules)
> >
> >   
> >> Is it distributed in an already-compiled form, or do you
> >> have to run "make" and such?
> >>
> >>     
> >
> > Binary distribution in major distros.
> >
> >   
> >> Can you say anything about fees for development and for runtime
> >> licenses, if any?
> >>
> >>     
> >
> > none
> >
> >   
> >> What's the history of this implementation?  For example, where was it
> >> originally written?  Is it a fork of another implementation?  What
> >> institutions were in charge of it at various points in its lifetime?
> >> Where did the CLOS implementation come from?
> >>
> >>     
> >
> > GCL has a very long history.  Origins in Kyoto Common Lisp, extensive
> > modification by William Schelter at UT austin (AKCL), official
> > adoption by the GNU project, most common base for many open source
> > lisp projects (acl2, axiom, hol88, nqthm, one of the most common
> > maxima platforms)  CLOS comes from pcl.
> >
> >   
> >> Does it come with its own interactive development environment (IDE)?
> >> What IDE's are availabile?
> >>     
> >
> > Basically no, but some emacs lisp ide files included in the
> > distribution.  Most users use emacs and an interactive shell window,
> > with tags completion, lisp shortcuts, etc.
> >
> >   
> >> Please describe good things about this Common Lisp implementation that
> >> would make people want to use it rather than other implementations.
> >>
> >>     
> >
> > Native object compilation, execution, runtime loading, and saving in
> > portable restartable disk images.
> >
> > GMP fast bignums
> >   
> What does "GMP" mean?

The GNU mp library is widely regarded as the fastest bignum
implementation in the open source world.  GCL has closely integrated
its internals to make optimal use of this library.

> > 1 instruction function calls via C pointers, resettable at runtime to
> > a longer dubuggable path.
> >
> > Dynamic gc load balancing and optimization
> >
> > Faster generational GC runtime option based on read-only pages managed
> > via segfault trapping and mprotect.
> >
> > tail recursion elimination
> >
> > unboxed numerical computation support
> >
> > very fast
> >
> > gprof profiling
> >
> > in cvs:
> >   
> I'm not sure what you mean here by "in cvs". Do you mean that everything
> below is in the latest cvs sources but not in release 2.6.7?

The "head" or "trunk" branch of cvs is versioned 2.7.0.  This is
released into Debian unstable as gclcvs.  All major advancement
progresses here until finalization, while leaving the 2.6 series a
stable platform for the supported applications.

> > two word cons
> >
> > immediate fixnums
> >
> > compressed function source stored in image and used in automatic
> >  inlining
> >
> > mutual recursion autodetection and state-machine conversion
> >
> > basically complete ansi support
> >
> > unboxed complex arithmetic
> >
> > Full runtime access to external C shared library functions not yet
> > linked into the image, preserved across image saves, callable via one
> > instruction C pointer indirection.
> >
> > Fork-based parallelism, p-let, p-and and p-or.
> >   
> How does that work?  Without threads?

Yes.  fork provides copy-on-write memory pages, which means the child
process instantly inherits the parent's memory image, and only copies
pages as they are modified (written) post fork.  GCL allocates on the
C stack in the child to avoid GC calls there, which would write to
many pages.  The result is then printed in the child and read in the
parent across a socket.  Quite fast.  Latency is around 2ms.

The huge advantage in avoiding threads, of course, lies in preserving
a natural lisp syntax and keeping all the internals under the hood.
The user need not explicitly worry about locks, mutexes, memory
corruption, reentrancy/thread safety, spaghetti stacks, etc.  Any lisp
function which results in a printable result can be parallelized
without modification in this way.

> > MPI support
> >   
> What does "MPI" mean?

Message passing interface, a standard library API used by (mpich, lam,
openmpi ...) to synchronize data structures across many nodes in a
parallel computing cluster, aka "beowulf".  This can also be used on a
single machine to pass data via extremely fast SysV shared memory
between processes.

> > ...
> >
> >
> >   
> >> Some things I'm interested in:
> >>
> >> Is there support for locating the source code of functions and methods
> >> and so on, so that Emacs "Meta-."  can work properly?
> >>
> >>     
> >
> > Yes.
> >
> >   
> >> Is there a profiling facility?
> >>
> >>     
> >
> > Yes, via gprof.
> >
> >   
> >> Are there user-defined extensible streams?  (Gray streams, simple streams?)
> >>
> >>     
> >
> > No.
> >
> >   
> >> Are there native threads, non-native threads, or no threads?
> >> (This may depend on the operating system or hardware.)
> >>
> >>     
> >
> > Parallelism is fork and MPI based (no threads)
> >   
> I guess, same question as above. This seems to be something different
> from anything I've seen in other Lisp implementations.
> 

Yes.  This is a deliberate design choice, though not (currently) the
most common.

Take care,


> Thanks!
> 
> -- Dan
> 
> 
> 
> 

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