Re: benchmark results [again]

[Mathieu Lacage <Mathieu dot Lacage at sophia dot inria dot fr>]

On Fri, 2005-02-04 at 16:56 -0500, Bryce McKinlay wrote:
> Its great to see that GCJ is competitive here! Note that with this sort 
> of runtime, startup time can be a significant factor in your results, 
> and GCJ should always beat JITs there. It might be interesting to see 
> what happens with a larger data sets and thus longer runtimes. On some 
> benchmarks I've noticed that GCJ wins easily on smaller data sets but 
> Sun's Hotspot VM gains back the lead as the runtimes increase and it has 
> more time to optimize.

No, my experiments have shown that 4 seconds of runtime is about what is
required for the sun JVMs to correctly optimize the hot paths of this
rather small application. You can see below two runs 1-minute long which
show that gcj still performs better than the sun JVM.

The only thing which might make the SUN JVM win is for really really
long runs (typically on 200000 iterations) because the GC dominates
runtime at this point but I have never been able to complete a run for
such iteration numbers (I stopped the simulations after 20 hours of
runtime).... 

A potential optimization might be to mark certain data structures as
"infinite life" such that the GC does not try to GC them ever because I
know they will be alive until the end of the process.

[mlacage@chronos treegrowth-stable]$ /usr/bin/time -
p ./native/MainSimulation --max-iterations=15000 --seed=1
real 64.68
user 64.38
sys 0.13
[mlacage@chronos treegrowth-stable]$ /usr/bin/time -p /opt/java/bin/java
-server -classpath build treegrowth.main.MainSimulation --max-
iterations=15000 --seed=1
real 92.99
user 76.10
sys 0.30


> Since checkBoundExclusive() is private, it ought to be inlined. Looks 
> like a bug.

yes. I will try to provide a simple test case.

> I believe we can optimize Jv_CheckCast and Jv_CheckArrayStore 
> significantly, so its "good" that these show up prominently in your 
> profile.

Cool. I might have a look at that then.

> It seems odd that ArrayList.size() shows up so prominently, since its 
> implementation is simply:
> 
>   public int size()
>   {
>     return size;
>   }
> 
> Perhaps something is calling it much more often than neccessary.

Not really: this call just happens to be on one of the critical paths. I
could restructure the code to avoid this but that would be quite a lot
of efforts. It looks like cross-shared-library calls are really
expensive.

thanks for your answer,
Mathieu
--