[Vm-dev] [VM-dev] Does reflective call (#perform:) jitted?

[Clément Bera]

I think reading Stefan Marr's paper on this topic can be interesting (the
paper is very good) [1].

I believe the important point in this optimisation is that the met
selectors are available for the sista optimiser, allowing speculative
inlining of the perform send site if one selector only is present in
practice. We could try to look into that and look at the impact on perform
benchmarks on the speedcenter.

[1]
https://hal.inria.fr/hal-01141135/file/pldi15-marr-et-al-zero-overhead-metaprogramming.pdf



On Thu, Nov 24, 2016 at 10:21 AM, Denis Kudriashov <dionisiydk at gmail.com>
wrote:

>
> Hi Eliot
>
> 2016-11-23 20:29 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>> I see.  That adds another path to linking send sites (first invocation of
>> a jitted perform: or when linking a send site checking for a perform
>> target), and to unblinking send sites on cache flush.  But it's eminently
>> doable.  I wonder if we have any volunteers willing to take a look or
>> whether it should get added to mine and Clément's lists (which are quite
>> full).  Denis, do you have any idea of the kinds of overhead due to perform
>> you have in meaningful benchmarks?  My guess is it's a very small part of
>> total overhead.
>
>
> Actually I don't think that it could really impact current UI
> applications. it could improve UI performance because bindings to objects
> are mostly based on #perform:, But I doubt it could be felt.
> But from other side in case of UI send sites will be megamorphic points
> because "pluggable" UI components are used with most domain objects during
> application runtime.
> So my question was more in theoretical field.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161124/7d4e94b3/attachment-0001.html>