Charles Oliver Nutter schrieb: > Jochen Theodorou wrote: [...] >> 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?
ok, let me try to explain what I think of... The current system in Groovy works like this: you have a narrow API, with some core that actually selects and executes the method call. Ng is more or less the same, but with a wide API. What I plan for the future is not no longer let the core execute the methods, instead they return handles to the call site and the call site will call the method for us. This design is very much oriented at invokedynamic, but we came up with this before invokednymic. Of course MethodHandles, such as described by John Rose will come in very handy here. Most of what can be done today with monkey patching and categories fits well in his new way. I plan also to restrict a MetaClass to be no longer replaceable, but mutating it is allowed. The downside of this is, that if you want for example write code that reacts to each method call, that you have to put that in a MetaMethod. But much of what is done today will work without change I think. I think this approach will allow a narrow API, with the core selecting the method, but not executing them. The actual call structure will be shallow and caching can be done at lots of places > 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. We plan on doing so too.. But only for a few cases that can be expected. In fact in Groovy the user can give type information, so if he does we can use that to predict methods and their result types. I plan such actions also for calls to private methods. This way the bytecode won't be that bloated >> 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. to say the truth, Groovy is fast enough for me, even if it is sometimes 5-100 times slower than Java. It is quite easy to get the speed very much up. But a language is not only about what the implementors want and a community driven language like Groovy especially not. Groovy is no academic language where you write papers when you have a good idea. Instead a language is also much about politics, and if the public demands more speed, then we will do our best. Also here are people afraid of dynamic languages and we need o show them, that they don't need to be slow, just because they are dynamic > 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? Well, in a benchmark like the Alioth Shootout you are not allowed to use this obvious solution. That gives bad press. And since a language is so much about politics, you have to handle bad press somehow 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 -~----------~----~----~----~------~----~------~--~---
