Re: benchmark results [again]

[Bryce McKinlay <mckinlay at redhat dot com>]

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