More indy perf anecdotes
Charles Oliver Nutter
headius at headius.com
Sun Apr 10 17:13:40 PDT 2011
On Sun, Apr 10, 2011 at 6:15 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> I think you can fix a little bit your implementation:
> First instead of sending the name of the operation at each call
> you should use the indy name to encode that name
> instead of pushing it on the stack.
> So fixnumFallback should bind the callsite and the indy name.
Yes, I would probably do that eventually, but I'd be surprised if it
made a difference here. I just didn't feel like encoding it for the
moment.
> You should precalculate all your MethodHandle get using
> a find(). As far as I know the VM will create a new MH each time.
> In PHP.reboot, I store them in different classes (one by operation)
> to avoid to initialize too much static variables at start-up.
That's a concern for the slow path, but the fast path should be seeing
that self instanceof RubyFixnum and going straight to the direct path.
I definitely intend to improve this in JRuby's current indy support,
since the overhead from bimorphic or worse call sites is *very* high
at the moment due to all the handles it recreates.
> When you find a MH (in a fast case or in slow case),
> you should call it instead of relying on self.callMethod().
Again, should not affect the fast case. Once the first call executes
and has bound the direct logic plus a GWT it should always be doing
fast path for this case.
> Also an interesting thing to test is that in that case you know
> the value of the constant (which is a primitive) so instead
> of pushing it as argument, you should try to send it as parameter
> of the BSM and bind it to your method handle.
> I wonder if it's more efficient ?
I thought about doing that, but other necessary objects do not get
passed to the BSM, like the actual target object, the current JRuby
instance, and so on. It's not possible to produce anything other than
a dumb, empty CallSite in the BSM without that information.
I probably could encode it into a class LiteralFixnumOperatorCallSite
< MutableCallSite.
Bottom line, though is that the fast path for the indy-based version
should be pretty close to identical to the hand-written logic.
- Charlie
More information about the mlvm-dev
mailing list