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

[Nicolas Cellier]

There is one use case for #perform: though, if we spread usage of Symbol
value: anObject, like (self collect: #sqrt).

2016-11-24 11:15 GMT+01:00 Clément Bera <bera.clement at gmail.com>:

>
> 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/0a8ee1b8/attachment.html>