[Gc] Performance evaluation
hans.boehm at hp.com
Tue Aug 10 11:44:32 PDT 2010
> From: Manuel.Serrano at sophia.inria.fr
> Hi Hans,
> > I'm a little confused about the units and axis labels here. What
> > exactly is being measured in each case? The 1.02x figures and the
> > are throughput? The other numbers are time? bigloo3.2b uses GC7.1
> > default, bigloo3.4b uses 7.2alpha4 unless stated otherwise? What
> > "3.2bMHz" mean?
> You are absolutely right. This is highly confusing. I have re-used a
> script to generate the barchart and not correctly changed the labels.
> What is measured here is the SYS+CPU time on the same machine (a Linux
> core I7, 3.2ghz with 6GB of RAM). The base time is bigloo3.2b + gc7.1.
> > On benchmarks like Traverse, the time increased significantly from
> > to 7.2alpha4? If I'm reading that correctly, is it easy to generate
> > GC log for the two cases? It's possible that we broke something in
> > 7.2alpha4. But I think we also may have fixed some bugs that could
> > caused 7.1 to allocate way too much heap space, and hence run faster.
> Yes. Traverse is the most annoying one but in general it looks like as
> if 7.2 was constantly a little slower. Do you want me to investigate on
> that particular benchmark. I can study the number of allocations, the
> allocated memory, the number of GCs.
I think it would be useful to have those numbers, particularly for one or
two of the bad cases, like Traverse. If the number of GCs and typical heap size
is the same, I'd be concerned that we broke something. If this is really
a change in the heap sizing heuristic, it would be good to verify that things
are behaving reasonably, and we're not running in a ridiculously small heap.
> > The configuration is the same in both cases, particularly with
> > to thread-support (incl. thread-local allocation, parallel marking)
> > debugging options?
> Yes. Exact same thing.
More information about the Gc