[gambit-list] Re: Gambit is great: the manual should advertise better

Bill Richter richter at math.northwestern.edu
Tue Feb 8 22:55:00 EST 2005


Thanks, Marc!  Real quick first: John Franks observed that the
gsc-created C code doesn't have any calls to `free' or `*alloc', but I
just checked that libgambc.so matches both.  So does libgambc.so,
called by `gcc ... -lgambc', set up the GC I get by gsc/gcc/a.out?

   > Please answer a question, asked by the computer hotshot Math
   > professor here John Franks (a Rice pal of Clarence): does gsc/gcc
   > implement a garbage collector?  I figure it must, looking at this
   > 112.6 GB, which you say is legit (and I've seen 435 GB too).  But
   > John points out that writing a garbage collector is serious work,
   > and gcc doesn't have one.

   Gambit's runtime system includes a garbage collector.  This garbage
   collector is written in C and is precise (it is not a conservative
   GC).  This is possible because the C code generated by the Gambit
   compiler manages its own runtime "stack" explicitly, and the GC
   knows how to parse the stack frames constructed by the compiler.

   I'm not sure what you mean by "does gsc/gcc implement a garbage
   collector?" because the gcc ***compiler*** actually contains a
   garbage collector (but not the code that gcc generates).  Moreover
   Gambit can be compiled with any C compiler, so the fact that Gambit
   contains a garbage collector has nothing to do with gcc.

May I recommend you explain this in the Gambit manual?  And speaking
of the manual, I haven't yet understood your position about
non-experts using Gambit for a huge speed increase.  Should I post
what I'm thinking to cls, or should I not?  Do you want to wait until
version 4 is out of beta?  My guess is that it's a very stable beta,
as Brad has been posting about it to cls for years.

Lotta interesting stuff here I should pass on: precise vs conservative
GC, gcc has an internal GC.  I knew you didn't have to use gcc.  By
"gsc/gcc", I meant that I type 

   % gsc tag-t-71.scm 
   % gcc -O2 -L. -I. tag-t-71.c tag-t-71_.c -lgambc
   % ./a.out 

and (as I just ran again) it took 16.8 minutes, incl 6.0 minutes of
GC, using 112.6 GB on a 1GB machine, and `ps -aux' says I never used
more than 8%.  Looks like Gambit must be flushing data out of memory
in an amazing & efficient way.  Especially as mzscheme ran this job
6.2 times slower, i.e. in 104.7 minutes, with only 7.5 minutes of GC:

75299
(4 8 4 5 3 5 9 3 5 7 7)
(3 4 4 2 3 5 3 5 9 7 7 7)
cpu time: 6282240 real time: 6316034 gc time: 455500


Here's my call to strings on libgambc:

(morse)PolyTree> strings /rhome/richter/my-gambit/lib/libgambc.so | grep alloc
___alloc_mem
___alloc_scmobj
___alloc_global_var
___alloc_rc
___bytes_allocated
malloc
Heap overflow while allocating stack marker

(morse)PolyTree> strings /rhome/richter/my-gambit/lib/libgambc.so | grep free
___free_mem
___free_UCS2STRING
___free_NONNULLUCS2STRINGLIST
free
freeing h=%p



More information about the Gambit-list mailing list