On Mon, Sep 15, 2014 at 10:57 AM, Nick Wellnhofer <[email protected]> wrote:
> IMO, the main benefit is fast method dispatch without the need for the
> possibly huge itables arrays. The main downside is that the creation of
> interface objects is expensive. Using the same pointer for objects and
> interface objects has many benefits but it means that we have to find the
> correct method pointer on every method invocation which is either slow or
> memory-hungry.
I made some commits today to the method dispatch benchmark to explore what
kind of penalty we incur for interface method dispatch with an extra layer of
indirection. Here's the output on Linux:
LD_LIBRARY_PATH=. ./exe
cycles/call with method ptr loop: 12.894064
cycles/call with wrapper loop: 15.903370
cycles/call with fixed offset wrapper loop: 11.401846
cycles/call with interface loop: 17.897250
cycles/call with simulated inline: 6.756627
cycles/call with wrapper: 20.345853
So we go from ~15.9 cycles for our current class method dispatch to ~17.9
cycles for this flavor of interface method dispatch.
> I wouldn’t rule out this approach so quickly. We should also still consider
> “traditional” interfaces where every class must declare the interfaces it
> implements explicity. This would make both the cast to interface types and
> method dispatch extremely cheap.
Sure, but how much cheaper can we get? It doesn't seem like the penalty is
all that severe.
It occurs to me that an additional optimization is possible for all flavors of
interface method dispatch. Since adding a new abstract method to an interface
is a backwards compatibility break, we could sort the abstract methods by name
and assign fixed offsets.
This leads to another topic I wanted to cover: I would really like to allow
interfaces to define concrete methods in addition to abstract methods.
Allowing concrete methods facilitates stuff like Ruby's Comparable, where
defining `<=>` gets you 6 other methods:
http://www.ruby-doc.org/core-2.1.2/Comparable.html
Sometimes people use "trait", "role", or "mixin" instead of "interface" to
describe such a construct. In any case, for Clownfish I'm suggesting that
interfaces may define additional methods but with the limitation that these
methods may not access any ivars.
Marvin Humphrey
