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.
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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
