DaCapo benchmarks

[David Daney]

Andrew Haley wrote:
> Bryce McKinlay writes:
>  > Andrew Haley wrote:
>  > 
>  > >The gcc exception processing mechanism is designed to be very fast for
>  > >the "never thrown" case, but it is slower when exceptions are thrown.
>  > >I suppose gcj could change to optimize for things like this, but IMO
>  > >it would not be such a good idea for "reasonable" applications.
>  > >
>  > >I'm very tempted to fix getValueOf() so that it does what its
>  > >specification requires, but that would invalidate the benchmark.
>  > 
>  > Even HotSpot is slow for thrown exceptions (though not as significantly 
>  > as GCJ), and Sun recommend against using exceptions to signal 
>  > non-exceptional conditions. So in cases like this there is a pretty good 
>  > argument for submitting a fix upstream, since the application will 
>  > perform better on most/all implementations - not just GCJ.
> 
> Good idea.  I'll try doing that.
> 
>  > However, its also true that exception performance will continue matter 
>  > in many real-world apps, and anything that can be done to speed up 
>  > throwing in GCJ would be good.
> 
> Well, one of the obvious ways to make throwing faster is to compile
> libgcj with a frame pointer and use the call chain to capture the
> stack trace rather than using the unwinder.  That would improve the
> performance of this particular benchmark severalfold, but I'm pretty
> sure it's a bad thing to do.
> 
> I don't know, really.  Sure, I care about benchmarks and so do our
> users.  But ...

... crippling the compiler so that this poor coding style is optimized 
at the expense of sane programs is not the way to make this user happy.

I feel strongly it is far more important to have the non-exception paths 
be as fast as possible.  Setting up a frame pointer is often in direct 
conflict with this goal.

David Daney