Jochen Theodorou wrote: > 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.
That sounds pretty exciting. Can you elaborate at all? One strategy I had though of for at least a subset of operations was compiling both direct calls and dynamic calls into the bytecode. That approach unfortunately has a major down side: LOTS more bytecode generated. Instead, for at least the primitive operators I have specialized call sites that can skip method lookup when the target type is, for example, Fixnum, and the methods have not been overridden, as Ruby 1.9 does. It would give us a small additional boost, but inline caching and shortening the call path has done far more for us up to this point. > 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? No, we're certainly not doing calculations as fast as in Java. If you compare us to ints, we're much slower, slower enough that any advantage we have over Ruby 1.8 is not significant. My point is that people using JRuby are using it for Ruby, and at the moment there's small enough demand for higher performance that native primitives isn't worth the effort. At some point in the future, it might be. I have a different question for you: Since Groovy lets you easily write some code in Groovy, some in Java...why the recent interest in making primitive math faster? I think many Groovyists woulds say "write it in Java", and there's probably other Groovy-specific areas that would be a more broadly applicable use of the time. Am I misunderstanding something? - 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 -~----------~----~----~----~------~----~------~--~---
