More performance explorations
Charles Oliver Nutter
headius at headius.com
Sun Jun 5 04:18:10 PDT 2011
On Sun, Jun 5, 2011 at 6:06 AM, Rémi Forax <forax at univ-mlv.fr> 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
More information about the mlvm-dev
mailing list