> I've modified his patch to remove some unnecessary calculations.
>
> before after
> gc_alloc_new.pbc 4.155999 3.756002
> gc_alloc_reuse.pbc 16.574 9.423002
> gc_generations.pbc 4.025 5.278002
> gc_header_new.pbc 3.686 3.615
> gc_header_reuse.pbc 5.577999 4.908003
> gc_waves_headers.pbc 3.815002 3.675001
> gc_waves_sizeable_data.pbc 8.383002 9.403999
> gc_waves_sizeable_headers.pbc 5.668 6.268999
Yet another correction to my results...the 'after' benchmarks are from a
completely different build of parrot. Unfortunately, the new results
aren't any easier to explain.
Correct results are:
before after
gc_alloc_new.pbc 4.155999 3.836001
gc_alloc_reuse.pbc 16.574 12.318001
gc_generations.pbc 4.025 4.186
gc_header_new.pbc 3.686 4.166
gc_header_reuse.pbc 5.577999 4.345999
gc_waves_headers.pbc 3.815002 3.796001
gc_waves_sizeable_data.pbc 8.383002 7.27
gc_waves_sizeable_headers.pbc 5.668 5.617998
gc_waves_resizeable_data improves by 1.1
gc_header_reuse improves 1.2
gc_alloc_new improves 0.3
gc_alloc_reuse improves 4.2 (as it does for every benchmark)
gc_header_new worsens 0.5
gc_waves_resizeable_data improves because it closesly follows the shape of
the curve, instead of allocating lots of extra memory all the time. (not
sure how closely...depends upon when it runs out of pool memory and
copmacts..at the bottom of the curve or at the top).
Not really sure how to explain the other results, unfortunately. My
imagination has blown it's cover and been exposed for what it is, and it's
having some trouble recovering. :)
With these new stats, this patch looks like it *does* provide an
improvement, and so I think this one is worthwhile (although my comments
still stand about looking for an adaptive pool sizing system).
Thanks for bearing with me on this,
Mike Lambert
