performance degeneration from jdk7u2 to jdk7u6?

[Christian Thalinger]

On May 30, 2012, at 2:16 PM, Jochen Theodorou wrote:

> Am 24.05.2012 13:43, schrieb Rémi Forax:
> [...]
>> if invokedynamic knows more, you can provide a path with
>> less boxing so it's usually better.
> 
>  I changed Groovy to get rid of getCallSiteArray and added 
> backpropagation of the return type to the next directly involved method 
> call. So in
> 
> int fib(int x) {
>     if (x<=1) return 1
>     return fib(x-1)+fib(x-2)
> }
> 
> the plus will now have directly return type int, instead of Object.
> 
> In a first iteration I made a primitives taking minus method, that also 
> returns int. And nice, runtime is down from 3.5 (on update 2) to 2.5 (no 
> tiered compilation and update 6).
> 
> That is not yet making really use of the type back propagation, so in 
> the next iteration I added a (II)I plus method as well. Before the 
> callsite target type was (II)Object, now it is (Object,Object)I, so only 
> little I can save on boxing, but let us see... 2.1s! And it stabilizes 
> much faster than before too. That's almost as much gain as before (in 
> percent). Certainly more than I thought.
> 
> Had I only used the plus method and not the minus method as well, I 
> would have ended up with 4.2s. only both together do make it that fast 
> now. A behaviour I noticed with primitive optimizations as well. An 
> optimization done in isolation can make things slower or does show only 
> little gain, but in combination they are suddenly much better. Another 
> interesting aspect is, now I don't see the slowdown through tiered 
> compilation anymore. The times are more or less equal with and without 
> tiered compilation, while before it was always slower with tiered 
> compilation not disabled (in update 6 it is on by default).
> 
> So the current state of my fib program is:
> 
> indy: 2.1s
> primopts: 1.2s
> callsite caching: 4s
> 
> Now I know that using catchException is causing quite a problem for 
> indy, so I removed that guard for the math operations plus and minus. It 
> is legal, since in those cases I can be certain I don't need it. And now 
> indy is at 1.2s! That means primopts and indy are no on par. That's very 
> cool! I mean I expected indy to come near indy, but to actually get on 
> par with it... I would never have thought that is possible.

Sorry, I was to busy to even read this thread, yet.  But cool you figured it out :-)

-- Chris

> 
> The assembly is still quite big: http://rifers.org/paste/show/1717
> But much better already.
> 
> bye Jochen
> 
> -- 
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev