Front page | perl.perl6.internals |
Postings from July 2002
Re: [COMMIT] GC Speedup
From: Mike Lambert
July 24, 2002 21:25
Re: [COMMIT] GC Speedup
Message ID: Pine.LNX.email@example.com
> With the call to trace_system_stack commented out in dod.c, I get 48.5
> generations per second. The full stats are:
> 5000 generations in 103.185356 seconds. 48.456488 generations/sec
> A total of 36608 bytes were allocated
> A total of 42386 DOD runs were made
> A total of 6005 collection runs were made
> Copying a total of 72819800 bytes
> There are 21 active Buffer structs
> There are 1024 total Buffer structs
> This compares to the 14th July CVS version:
> 5000 generations in 81.172149 seconds. 61.597482 generations/sec
> A total of 58389 bytes were allocated
> A total of 160793 DOD runs were made
> A total of 1752 collection runs were made
> Copying a total of 1228416 bytes
> There are 81 active Buffer structs
> There are 192 total Buffer structs
I guess this means the examples/benchmarks I was using to test were not
too representative of real-world programs. Or maybe that's the case for
Looking at the above results, I think I can see part of the problem.
What's really annoying is that the more I play with the benchmarks, the
more I realize they are useless. The new parrot has an initial buffer
count of 256, which helped performance on my system, when compared to the
pre-GC commit. The old version has 64 or so. Just this small tuning
a) more buffers to dod and collect
b) less of a need to DOD since we can "live" longer without it
c) more memory usage because we can't collect data in old PMCs until
they've been DOD'ed
Doing minor adjustments like inlining functions, etc (which I did the
other day) can give maybe a 1-4% performance across the board, each.
However, changing a number like HEADERS_PER_ALLOC can affect performance
This makes it rather difficult to difficult to optimize the GC, since
optimizing for one program *easily* messes up the performance on other
Setting *_HEADERS_PER_ALLOC back to the original of 16 improves
performance on life.pasm by 5%, although it causes a corresponding hit on
Changing UNITS_PER_ALLOC_GROWTH_FACTOR either way causes a big speed hit.
Changing REPLENISH_LEVEL_FACTOR either way causes a big speed hit.
Changing the logic on when we DOD relative to collection, in any manner,
causes a speed hit.
This leads me to believe that we have a GC that's tuned for life.pasm,
which makes a lot of sense. Before examples/benchmarks, there was only
life, and all GC performance changes were compared on that. In my attempts
to tune for examples/benchmarks, I undoubtedly caused life performance to
suffer. Parrot doesn't have any real-world programs, which makes it
difficult to do any sort of worthwhile tuning.
Hopefully, with sean's (and everyone else's) work on the Perl6 grammar, we
can start taking these perl programs (like qsort), and running them
through and benchmarking them against the parrot VM. Unfortunately, until
we have a wide test suite of programs, or start implementing adaptive
adjustment of GC parameters, I have a feeling we're just going to travel
around in circles.