Hello.
I have another question on special cases for jitter.
Do VM has a kind of PIC for reflective calls like #perform:? In addition to receiver class it could also check selector from argument.
Hi Denis,
On Tue, Nov 22, 2016 at 12:05 PM, Denis Kudriashov dionisiydk@gmail.com wrote:
Hello.
I have another question on special cases for jitter.
Do VM has a kind of PIC for reflective calls like #perform:?
No. The perform: primitive is in machine code and probes the first-level method lookup cache. If it finds a hit it either jumps to the entry point (if the method is fitted) or enters the interpreter (if the method is not). The issue here is that the cache needs to be at the send site, but there is nothing special about the #perform:[with:*] selector. Whether the send is a perform or not depends on the send binding to a method containing as perform: primitive.
In addition to receiver class it could also check selector from argument.
What exactly do you mean here?
_,,,^..^,,,_ best, Eliot
On Wed, Nov 23, 2016 at 12:51 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Denis,
On Tue, Nov 22, 2016 at 12:05 PM, Denis Kudriashov dionisiydk@gmail.com wrote:
Hello.
I have another question on special cases for jitter.
Do VM has a kind of PIC for reflective calls like #perform:?
No. The perform: primitive is in machine code and probes the first-level method lookup cache. If it finds a hit it either jumps to the entry point (if the method is fitted) or enters the interpreter (if the method is not). The issue here is that the cache needs to be at the send site, but there is nothing special about the #perform:[with:*] selector. Whether the send is a perform or not depends on the send binding to a method containing as perform: primitive.
In addition to receiver class it could also check selector from argument.
What exactly do you mean here?
Hi,
I think he's talking about Stefan Marr optimisation. For perform, you could have a first inline cache at send site, and when finding the perform primitive, instead of relinking to the machine code of perform, it would create a second PIC-like cache which compares again already met selectors and directly dispatch to the method to be performed. It would move perform cache from a global cache in the primitive to per send site caches, speeding up perform. In addition, the Sista optimiser could read the selector information.
_,,,^..^,,,_ best, Eliot
2016-11-23 8:04 GMT+01:00 Clément Bera bera.clement@gmail.com:
No. The perform: primitive is in machine code and probes the first-level
method lookup cache. If it finds a hit it either jumps to the entry point (if the method is fitted) or enters the interpreter (if the method is not). The issue here is that the cache needs to be at the send site, but there is nothing special about the #perform:[with:*] selector. Whether the send is a perform or not depends on the send binding to a method containing as perform: primitive.
In addition to receiver class it could also check selector from argument.
What exactly do you mean here?
Hi,
I think he's talking about Stefan Marr optimisation. For perform, you could have a first inline cache at send site, and when finding the perform primitive, instead of relinking to the machine code of perform, it would create a second PIC-like cache which compares again already met selectors and directly dispatch to the method to be performed. It would move perform cache from a global cache in the primitive to per send site caches, speeding up perform. In addition, the Sista optimiser could read the selector information.
Yes, exactly.
Hi Denis, Hi Clément,
On Nov 23, 2016, at 1:01 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
2016-11-23 8:04 GMT+01:00 Clément Bera bera.clement@gmail.com:
No. The perform: primitive is in machine code and probes the first-level method lookup cache. If it finds a hit it either jumps to the entry point (if the method is fitted) or enters the interpreter (if the method is not). The issue here is that the cache needs to be at the send site, but there is nothing special about the #perform:[with:*] selector. Whether the send is a perform or not depends on the send binding to a method containing as perform: primitive.
In addition to receiver class it could also check selector from argument.
What exactly do you mean here?
Hi,
I think he's talking about Stefan Marr optimisation. For perform, you could have a first inline cache at send site, and when finding the perform primitive, instead of relinking to the machine code of perform, it would create a second PIC-like cache which compares again already met selectors and directly dispatch to the method to be performed. It would move perform cache from a global cache in the primitive to per send site caches, speeding up perform. In addition, the Sista optimiser could read the selector information.
Yes, exactly.
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.
Hi Eliot
2016-11-23 20:29 GMT+01:00 Eliot Miranda eliot.miranda@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.
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-metap...
On Thu, Nov 24, 2016 at 10:21 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
Hi Eliot
2016-11-23 20:29 GMT+01:00 Eliot Miranda eliot.miranda@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.
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@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@gmail.com wrote:
Hi Eliot
2016-11-23 20:29 GMT+01:00 Eliot Miranda eliot.miranda@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.
vm-dev@lists.squeakfoundation.org
-
Clément Bera -
Denis Kudriashov -
Eliot Miranda -
Nicolas Cellier