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