Jochen Theodorou wrote: > Charles Oliver Nutter schrieb: >> A few JRuby techniques to reduce argument boxing: >> >> * We have specific-arity call paths for up to three arguments and with >> or without a block. The compiler calls one of those when it can do so, >> and calls the default [] version otherwise. This means that from the >> call site down, there's 10 paths straight through to the eventual code. > > 10? that sounds like pretty much..
zero args, no block zero args, with block one arg, no block one arg, with block two args, no block two args, with block three args, no block three args, with block n args, no block n args, with block The block/no block split is there because blocks can result in non-local flow control while normal methods can't. So by having two paths we can eliminate the flow-control exception handling most of the time. > ok.. but how is that helping in avoiding boxing or get calculations faster? Previously, all calls boxed argument lists in [], resulting in a lot of time wasted constructing, populating, access, and collecting those arrays. The above work eliminated that cost for a majority of calls to core methods. So with current JRuby, 1 + 2 passes the '2' as a Fixnum object through a CallSite, a method handle, and into the target method without ever having to box it in an array. > 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. And of course we box all numeric types, so we have the same problem (if you consider it a problem). > 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. 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. 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. - Charlie --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
