More indy perf anecdotes

[Rémi Forax]

On 04/11/2011 02:13 AM, Charles Oliver Nutter wrote:
> 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.

I'm not sure that the LDC with the name is eliminated.

>> 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.

yes, BTW I forgot to mention that you can compare Class with ==
instead of doing a instanceof.

> 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.

yes, you can only send true constant.

> I probably could encode it into a class LiteralFixnumOperatorCallSite
> <  MutableCallSite.

You don't have to encode it in the callsite, you can bind it as
a parameter of your fallback method.
Also, if you do that you will know if the integer is positive
or not which you can use to simplify the handling of overflow.
e.g. x + 1 can't overflow from negative to positive, only from
positive to negative so testing if x == Integer.MAX_VALUE - 1
is sufficient.

> Bottom line, though is that the fast path for the indy-based version
> should be pretty close to identical to the hand-written logic.

Yes, but currently, John correctly me if I'm wrong, there is still
a supplementary checks that the callsite target has not changed.

> - Charlie

Rémi