benchmark results [again]

Sun Feb 6 12:01:00 GMT 2005

Mathieu Lacage wrote:
I did a complete cvs update from the trunk today and ran again my
application code and oprofile on it. I have put quite a bit of micro-
optimizations on the current codebase since my last benchmark results
which means that it would not make much sense to compare these results
to the previous results. However, it is nice to see that now, gcc
outperforms every jdk on this dataset.

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.
opgprof /opt/gcc-4.0.0/lib/libgcj.so
gprof /opt/gcc-4.0.0/lib/libgcj.so -p gmon.out 
Each sample counts as 1 samples.
 % cumulative self self total
time samples samples calls T1/call T1/call name
18.74 250.00 250.00 Jv_CheckCast
11.24 400.00 150.00 ZN4java4util9ArrayList4sizeEv
10.79 544.00 144.00 GC_mark_from
10.42 683.00 139.00 Z20_Jv_IsAssignableFromPN4java4lang5ClassES2_
10.34 821.00 138.00 ZN4java4util9ArrayList3getEi
10.12 956.00 135.00 ZN4java4util9ArrayList19checkBoundExclusiveEi
 6.75 1046.00 90.00 frame_dummy
 6.15 1128.00 82.00 ZN4java4util9ArrayList3addEPNS_4lang6ObjectE
 5.70 1204.00 76.00 Jv_CheckArrayStore

Obviously, an optimization of the ArrayList implementation would be a
huge potential gain. The only worthwhile optimization I can think of
would be to inline by hand the code in checkBoundExclusive since it
seems not be inlined by the compiler as shown below.

Since checkBoundExclusive() is private, it ought to be inlined. Looks 
like a bug.
I believe we can optimize Jv_CheckCast and Jv_CheckArrayStore 
significantly, so its "good" that these show up prominently in your 
profile.
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.
Bryce