Charles Oliver Nutter schrieb: [...] >> I see... maybe the JRuby problem is just very different from the Groovy >> problem here > > Well, not really...you box all arguments in arrays too, and you're > paying a cost for that. Whether that cost is measurable in the face of > other overhead, I don't know. For us it has made a very measurable > difference.
of course creating those arrays is an overhead we have to pay too.. in my example it seems it gives an additional 50% to the runtime... meaning we are in the area of being 60-70 times slower than with primitive ints. But we target calling methods directly, without reflection, and then of course without arrays. > And of course we box all numeric types, so we have the same problem (if > you consider it a problem). I do. because as I said... working with primitive ints seems to be much faster, than using wrapper or value objects. And I am talking here about a factor of 40 or more. With partial boxing I am able to get this down to being 20x slower, but my goal would be to be less than 10 times slower. Also generating bytecode that can handle the primitive types along with the rest is not an easy task. It is one thing for ints, at last they take only one slot, but double and long make it really difficult, because they take two slots and any stack manipulating code becomes really bad >> well... lets say you represent integers as Java ints, then I doubt there >> is something faster than iadd or a method call without doing any boxing >> executing iadd at the end. Of course that makes no sense if your >> language has no ints like Java has and if your ints have not the same >> overflow logic. Using Integer instead seems at last for plus to be >> around 20 times slower, using BigIntger around 200 times and using a >> custom wrapper object around 47 times.. only that the last ones have >> several advantages as they can be used to hold multiple different values >> and keep overflow flags and such... Well such a holer would then of >> course still need adaption if you want to call a Java method taking >> primitive ints with it. > > It's worth mentioning that unless you want to change the semantics of > groovy quite a bit, I suspect unboxing is going to be really hard to add > after the fact. For example, in JRuby, in order to unbox, we'd need to > have extra logic for every operation we want to perform against > primitives that would check whether the given value is actually a > primitive or not. We'd need to have logic for parameters to pass them as > primitive values rather than boxing and passing. We'd have to check or > ignore overrides to that set of operations. Any call paths that need to > pass through JRuby system would need to also accept unboxed primitive > values. I plan a major semantic change to Groovy... and this change aims to not to having to pass the values through the whole system, instead let the callsite handle this locally and with direct access to the values. method handles will be extremely useful here, but even without them we can do much. > And it may not even be worth it in JRuby. Ruby 1.9 uses tagged integers > for Fixnums with an overflow check to roll to Bignum which is a full-on > object. It has fast-paths for numeric operators that go straight to the > code bypassing dynamic dispatch, and those operators do a normal C-level > integer math operation on the values. And we're as fast or faster anyway > with our fully-boxed custom class wrapping a long. It's hard to justify > the work for us when we're the fastest production-worthy Ruby > implementations for most apps already. so you say you can theoretically do calculations in JRuby as fast as in Java? Or how much would you say are you slower than Java? > In general it seems like the time would almost always be better-spent > making dynamic dispatch faster and reducing per-call cost before trying > to get primitive math operations to run faster. the fastest call is one you never do ;) bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
