On Wed, 18 Dec 2002 John.Maloney at disney.com wrote:

> At 7:55 AM -0800 2/18/02, Alan Kay wrote:
> >Interval had a great submillisecond GC that was terrific for
> >real-time apps. Maybe we can get this from them now that they have
> >donated their work to Stanford (per Glenn Edens).
> >
> >Don't forget that the current GC (and any Squeak GC) has to handle
> >real time demands for animation and music, etc.
>
> Alan's point goes directly to the heart of the GC tradeoff: if you
> want to minimize the total GC overhead, and you don't mind a GC
> running for a few hundred milliseconds, then the number of allocations
> between GC's can be set to a high number, as Scott showed in his
> experiment. If, on the other hand, you're generating 20 or 30 voices
> of music in real time while doing animation, you want to break the GC
> work into chunks too short to be noticable, say under 10 milliseconds.

3mb more RAM, and one incrGC every 40k allocs will do this on a P2-450.

> In this case, you're willing to let the GC do more total work in order
> to avoid noticable pauses. One might call this the "proactive"
> approach to garbage collection.
>
> Different applications benefit from different settings, which is one
> reason the parameters can be changed at run time. (The other reason is
> to allow experiments such as the one Scott just performed. :-)) The
> current defaults were set to allow smooth real-time multimedia on a
> 100 MHz PowerPC or equivalent. Because Squeak was developed for a
> community of teachers and children, we believed (and still do) that
> the default settings should support multimedia even on older machines.

Ah, that explains why they're so low. But, I suspect that a lot of the
uses of squeak are not that hard realtime, or not on that sort of
hardware. So, the GC parm are specifically designed for the hardest task
on the slowest hardware, when both of them are relatively uncommon, both
individually, and especially in combinations.

> Now that many schools are upgrading to iMacs, it might be worth
> increasing the defaults a little, or, as John Mcintosh suggested
> writing some startup code that automatically sets the GC parameters to
> values that support low-latency GC's.

Yes, I'd have a latency knob, and try to optimize GC paramaters so that
the average latency is within, say, the ranges of:
  very low  <4ms
  low       <40ms
  medium    <100ms
  high      <400ms
  very high >1000ms

Note that at 'very high', you're feeding squeak 200mb or more of RAM, and
only paying that GC every 20-60 seconds.

Roughly, I profile it at:

 Can GC 60mb in 170ms, or about 360mb (6m objects) in a second.
 Can incrGC 300MB in 1600ms.  Can fullGC 20MB in 400ms
     (P3-500 laptop)
--

But, being adaptive depending on the applications is best.

> Scott's experiments show that there's a factor of three in GC overhead
> between the current parameter settings and an extreme setting when
> Squeak has 500 MB of real memory available. It would be interesting to
> plot some of the points in between for the same set of benchmarks. Is
> it a linear relationship or is there a "knee" in the curve? This data
> might help John Mcintosh with his idea of adaptively setting the GC
> parameters at startup time.

Its probably a knee, but the knee will be in a different part for each
application, or for different datasets for the same applications.



Scott