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