wacky micro-benchmark

[steve goldman]

Kirk Pepperdine wrote:
> I've been fiddling with the loop invariant hoisting optimization trying to
> demonstrate how it works. In my first iteration I used a long to sum up the
> invariant in a loop. First run with -Xint showed 7.6 seconds for the hoisted
> version and 15.4 for the non-hoisted version. Pretty much as one would
> predict. Running with -client I see 3.5 seconds for hoisted and 6.3 for
> non-hoisted. A bit of surprise because I figured the client would hoist the
> invariant but it appears not to have. Then things got weird when I ran with
> -server. The hoisted code ran in 6.3 seconds and non hoisted in 6.4. Now, I
> expected the values to be about the same but not towards the slower end of
> the spectrum.

As John Rose already stated micro-benchmarks are tricky and unless you 
look at the generated code you are often surprised. Heck the compiler 
writers are often surprised. You have a lot of other variables to worry 
about when shifting from client/server. The compile threshold for server 
is 10x the client compiler. Also it appears that the code you have here 
will probably have to do an OSR (on stack replacement) to get to 
running compiled code. It's not too surprising that the results are 
surprising.

> 
> I of course immediately suspected that the benchmark is bad as that is
> usually is the case more often than not. However after lots of fiddles
> (checking for mono/poly morphic optimizations... etc) I was unable to get a
> different result which now leaves me wondering, is there something with long
> in loop invariants that results in a slower optimization than expected? And
> why would the client compiler not hoist the invariant.

The client compiler is not an optimizing compiler. You should suspect 
that it doesn't hoist loop invariants. As far as the server compiler 
there should be anything special about long vs. ints. they should all be 
treated the same by the global value numbering.


-- 
Steve