On Sun, Jun 5, 2011 at 6:06 AM, Rémi Forax <[email protected]> wrote: > 7 already performs well. > But yes, compared to a top notch JVM based dynamic language runtime, > 7 has some performance glitches. > > But please don't forget that implementing a runtime with invokedynamic > is a way easier that to write one without it.
Yes, quite true. And if I were starting from scratch, I'd most definitely go invokedynamic-only. But I'm not starting from scratch, and the various tricks I've implemented for JRuby still (mostly) beat invokedynamic performance. Consider my constant nagging as pushing the JVM guys to beat what I've spent 4 years making JRuby do as well as possible without invokedynamic. :) > Also invokedynamic performance is already stellar if you have primitive > types > in the signature compared to other runtimes. > By example, for JRuby, x + 1 can have a dedicated fast path that: > - doesn't require to box 1 to a Fixnum. > - has a specific overflow check. > This kind of optimization is hard to implement without invokedynamic. I have that optimization in place now (at least passing a primitive long; no special logic for overflows) and it inlines and optimizes quite well. In fact, when I last attempted to implement the same with invokedynamic, invokedynamic was *much* slower than my special-cased CallSite subclasses. So I backed off from that path for a while. I agree that invokedynamic makes it considerably easier to build in these special-cased call paths, and that it should eventually be as fast as my specialized CallSite subclasses. But until it's consistently faster, I can't use it in those scenarios. (I do want to!) That said...I have not recently re-attempted installing invokedynamic-based primitive call paths. I'll give it another shot this week and see where we stand. Testing a simple loop ought to show quickly the overhead of invokedynamic versus my call sites. Another quick note...EA is still not enabled across invokedynamic call sites, but my specialized call sites *could* potentially EA in some cases. I'm not saying they do, since in most cases the return value does escape (potentially across an invokedynamic anyway), but it's another factor. - Charlie - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
