On Tuesday, February 19, 2002, at 02:15 AM, Scott A Crosby wrote:

>>
>> Well, I just tried it for the VM parameter 4, and setting that to 40000
>> was actually measurably *slower* than setting it at 4000 (135s vs.
>> 130s).  The numbers of incremental GCs were typically around a factor 
>> of
>> 10 lower, and the time devoted to incremental GCs also significantly
>> lower, but the total running time of each of the individual benchmarks
>> increased.
>
> Strange.. As #4 is a read-only parameter. (See source for 
> vmParameterAt:)

It was parameters 5 and 6, not 4 and 5.  Late here.

> Methinks you're seeing measurement noise.

No, the results are consistent and persistent.

>>
>> Also setting vmParameter 5 to 12000 (in addition to vmParameter 4 to
>> 40000) further slows down the macro-benchmarks, to 148 seconds.
>
> Methinks you're seeing measurement noise.

No.

> Also, macrobenchmarks allocates all but 10mb before benchmarking, remove
> that code.

OK, did that, then re-ran the benchmarks with a variety of settings.

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...)

Smalltalk vmParameterAt: 5 put: 2000.
Smalltalk vmParameterAt: 6 put: 1000.
Smalltalk macroBenchmarks.


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

"How low can you go",  2K/1K got worse again:  127820, 127739



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


Marcel