Impacts of the squeak garbage collector

Scott A Crosby crosby at qwes.math.cmu.edu
Tue Feb 19 18:03:52 UTC 2002


On Tue, 19 Feb 2002, Marcel Weiher wrote:

>
> On Tuesday, February 19, 2002, at 02:15 AM, Scott A Crosby wrote:
>
> With CocoaSqueak 3.2, on a dual 1GHz G4/512MB total RAM, 128MB allocated
> to Squeak, image size 17MB.
>
> The parameters that were varied were VM parameter 5/6, using the
> following doit (parameters varied accordingly...)

[*] You also changed macrobenchmarks to not allocate all-but-10mb of RAM
before starting the benchmark?

> Default parameters 4K/2K:   128262 , 130944, 127643
>
> Parameters increased to 40K/12K:  141371, 141350, 148059
>
> Smaller increase, smaller slowdown 10K/12K:  136736
>
> Parameters accidentally decreased to 4K/ 1.2K:  125945
>
> Intriguied, I set param 6 even lower, to 4K/1K and got:  124051, 124079

Verry interesting.. Caching issues for the CPU cache? My CPU is only half
the speed of yours, so caching issues may be more important to you than
me.. I've also got a different architecture. What are the times spent on
GC for the respective sizes? Is GC using less time, but the overall
benchmark getting worse?

I tried roughtly the same type of analysis to see if caching issues had
any effect and didn't see any.

The main effect I saw was lower GC times when I set them very high and
disabled [*] above to allow it to use all the RAM.

Also, I used much larger numbers:
  400k/12k   (which is the default I use now)
  4000k/12k

with 256mb or more allocated to squeak.

>  From these measurements, the sweet spot seems to be at somewhat lower
> settings than the current default, at 4K/1K.

Yup.. Experimentation is needed. THanks for doing this on the PPC, and I'm
sorry for not believing you.

Scott





More information about the Squeak-dev mailing list