Newsgroups: comp.lang.dylan,comp.lang.functional,comp.lang.misc,comp.lang.scheme,comp.object,comp.lang.java
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.psc.edu!hudson.lm.com!news.math.psu.edu!chi-news.cic.net!simtel!news3.noc.netcom.net!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: (debunk-myth '(debunk-myth '(<-efficient gc malloc/free)))
Message-ID: <hbaker-0211951127210001@10.0.2.15>
Sender: hbaker@netcom22.netcom.com
Organization: nil organization
References: <pb8pwfk9sbi.fsf@concerto.best.com> <472rjd$8s4@camelot.ccs.neu.edu> <475p3j$hhd@news.parc.xerox.com> <478rou$93u@camelot.ccs.neu.edu>
Date: Thu, 2 Nov 1995 19:27:21 GMT
Lines: 42
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5807 comp.lang.functional:6629 comp.lang.misc:23635 comp.lang.scheme:14236 comp.object:40180 comp.lang.java:3669

In article <478rou$93u@camelot.ccs.neu.edu>, will@ccs.neu.edu (William D
Clinger) wrote:

> boehm@parc.xerox.com (Hans Boehm) writes:
> >  Agreed, except that it would be really nice to see some of this
> >backed up with empirical evidence....
> 
> In FPCA '93, Sansom and Peyton Jones reported on the performance of
> generational garbage collection for three real programs that ran for
> 3-6 minutes and allocated 190-585 megabytes of storage.  (This paper
> is also the only paper I have seen that uses an exponential time
> scale to display the distribution of object lifetimes.)
> 
> None of the Gabriel benchmarks allocate enough storage to challenge
> any modern garbage collector.  If a pair occupies 8 bytes, then only
> four of the Gabriel benchmarks allocate more than a megabyte:
> 
>     dderiv  2.8 megabytes
>     deriv   2.24
>     browse  1.91
>     boyer   1.81
      ^^^^^^^^^^^^

Bob Boyer has shown how to convert this benchmark into one which is
_much_ harder.  If people are interested, I'll try to dredge out Bob's
email about this.

Also, you should be aware that the Boyer benchmark also has a 'trap door'.
There is a relatively simple trick (using hash consing and memoizing) that
allows the Boyer benchmark to be solved with only about 3,000 cons cells --
just a few Kbytes.  The same trick works for the harder Boyer, but since
you can crank up the difficulty arbitrarily, even the tricks no longer
help.  However, the harder Boyer, together with the tricks, make for a much
more robust benchmark, since it is trying to do something intelligent instead
of something stupid.

ftp://ftp.netcom.com/pub/hb/hbaker/BoyerB.ps.Z  
ftp://ftp.netcom.com/pub/hb/hbaker/LBoyer.html  (also .ps.Z)

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
