harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm][gc_gen] gcv5 vs gcv41 comparison on Dacapo
Date Wed, 16 May 2007 07:31:09 GMT
Using a single fixed heap size for GC performance testing is a Bad Idea. 
  Only 5 of these benchmarks would require a GC (per iteration) in a 
900MB heap for a full-heap collector.  Fop, for example, only allocates 
100Mb.

Best to find out the min heap size for each benchmark and then do 
testing in a 2x or 3x heap.  You could try the Max Live figure from the 
dacapobench.org as a first approximation.

cheers

Vladimir Strigun wrote:
> Hi all,
> 
> Since default gc was changed to gcv5, I've done performance comparison
> between gcv4 and gcv5 with Dacapo benchmark. The next build was used:
> svn = r538104, (May 15 2007), Windows/ia32/msvc 1310, release build.
> Measurements were performed on Woodcrest machine, with 900M heap,
> large pages off. As the addition for the current code I used new
> charset encoders/decoders[1]. Each Dacapo benchmarks were executed 10
> times, final result calculated from last 5 values. I got the following
> numbers (the values are in milliseconds, so the less the better):
> 
> gc_cc.dll:
> antlr 1762
> bloat: 5927 (the benchmark failed after 6th iteration)
> chart: 7831
> fop: 1043
> hsqldb: 2290
> jython: 6790
> luindex: 5422
> lusearch: 2846
> pmd: 4071
> xalan: 2087
> 
> gc_gen.dll:
> antlr: 2354 (the benchmark failed after 7th iteration)
> bloat: 6005 (the benchmark failed after 6th iteration)
> chart: 7812
> fop: 1034
> hsqldb: 2219 (the benchmark failed after 6th iteration)
> jython: 6072
> luindex: 5478
> lusearch: 3569
> pmd: 27772
> xalan: 4547 (failed after 3rd iteration)
> 
> So, as the result we have 3 new failures (benchmarks not completed
> successfully), huge degradation for pmd benchmark, degradation for
> lusearch benchmark and significant speedup for jython. I'll continue
> to play with gcv5 - increase heap size, turn on large pages, etc.
> Should I create 3 separate JIRA issues for each failure or one issue
> is enough?
> 
> 
> Thanks.
> Vladimir.
> 
> 
> [1] https://issues.apache.org/jira/browse/HARMONY-3593


-- 
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

Mime
View raw message