Recent changes impeded building and testing on smaller boxes

[Luben Karavelov]

On Sat, 25 Sep 2010 11:39:22 -0700, Jonathan Leto <jaleto at gmail.com>
wrote:
> Howdy,
> 
> I share your concerns, Jim. Recently, parrot got a new commandline
> flag called --gc-threshold, which before was only changeable by
> twiddling some bits in the GC internals. The default value for this
> parameter, even before it was configurable from the command-line, was
> 25%, until r48585, where it was changed, in trunk, to 50%. The change
> was mixed in with other changes and is very easy to miss (the actual
> code is bitshifting a number of quantities) and did not involve any
> deprecation notice.
> 
My understanding is that default GC threshold was 50% until r48585. In 
that revision it was made to be 25%.

> The GC Threshold determines how much memory we are willing to waste
> before the GC says "take out the garbage!". If we "take out the
> garbage" too often, we lose performance. If we don't do it enough, we
> waste a lot of memory.
> 
> In theory, and I have seen some benchmarks (from luben++, IIRC),
> wasting a bit more memory (changing the threshold from 25 to 50%) gave
> nice speed increases for some Parrot benchmarks and Rakudo. But all
> was not peachy: for instance, the
> examples/benchmarks/stress_strings.pir benchmark got about 30% slower
> at r48585. It is a pathological benchmark for the GC, so it is still
> unclear how concerned about that we should be.

This benchmark runs slower with then default threshold of 25%, because 
parrot has to run more frequently GC. With threshold of 50% it runs as 
fast as before.

My un-scientific benchmarks showed that with threshold more than 300% 
parrot starts to run slower. Here is a chart of rakudo 
start time/consumed memory: http://luben.spnet.net/gc-time-mem.png .
Blue line is time in ms, red line is 6 times MB used by perl6 (in order
to make easy comparison of time and memory). My understandind is that 
75% is optimal compromise but it finally depends in the characteristics

of the underlying system. All benchmarks were run on linux/amd64 system
with 4G of RAM.

GC threshold parameter does not applies to current garbage collector.
It has fixed threshold of 256M. Nick Wellnhofer is working on porting
the old dynamic threshold system to the new garbage collector.


-- 
Luben Karavelov