What would be the consequence of implementing interfaces as fat pointers ?

All is in the title. This is becoming increasingly the norm in new languages. It is much better in term of performances (it avoid cascaded loads to call methods, which can be really costly on modern CPUs), make object themselves smaller. Would implementing them that way break D code ? What would be the extent of the breakage ?

On 3/29/2014 5:57 PM, deadalnix wrote: > All is in the title. > > This is becoming increasingly the norm in new languages. It is much better in > term of performances (it avoid cascaded loads to call methods, which can be > really costly on modern CPUs), make object themselves smaller. > > Would implementing them that way break D code ? What would be the extent of the > breakage ? D already has phat pointers - that's what delegates are. I'm curious how the scheme you propose is different?

On Sunday, 30 March 2014 at 01:04:27 UTC, Walter Bright wrote: > On 3/29/2014 5:57 PM, deadalnix wrote: >> All is in the title. >> >> This is becoming increasingly the norm in new languages. It is much better in >> term of performances (it avoid cascaded loads to call methods, which can be >> really costly on modern CPUs), make object themselves smaller. >> >> Would implementing them that way break D code ? What would be the extent of the >> breakage ? > > D already has phat pointers - that's what delegates are. I'm curious how the scheme you propose is different? I'm talking about interface here. The way they are implemented in most new language is via a struct that contains: - pointer to the object - pointer to vtable That way to don't make object bigger when they implement an interface, and you don't need cascaded load to call methods.

On 3/29/2014 6:11 PM, deadalnix wrote: > I'm talking about interface here. The way they are implemented in most new > language is via a struct that contains: > - pointer to the object > - pointer to vtable > > That way to don't make object bigger when they implement an interface, True, but why is this a problem? > and you don't need cascaded load to call methods. True, but on the other hand, it takes up 2 registers rather than one, costing twice as much to copy around, store, pass/return to functions, etc.

On Sunday, 30 March 2014 at 01:42:24 UTC, Walter Bright wrote: > On 3/29/2014 6:11 PM, deadalnix wrote: >> I'm talking about interface here. The way they are implemented in most new >> language is via a struct that contains: >> - pointer to the object >> - pointer to vtable >> >> That way to don't make object bigger when they implement an interface, > > True, but why is this a problem? > Higher memory consumption, less objects fitting in cache, more scanning to do for the GC. >> and you don't need cascaded load to call methods. > > True, but on the other hand, it takes up 2 registers rather than one, costing twice as much to copy around, store, pass/return to functions, etc. Two pointers structs are passed in register, which is fast. If that spill, that spill on stack, which is hot, and prefetcher friendly. On the other hand, the double indirection is very cache unfriendly.

"deadalnix" wrote in message news:jizqsnuigdsvxhtcsshl@forum.dlang.org... > All is in the title. > > This is becoming increasingly the norm in new languages. It is much better in term of performances (it avoid cascaded loads to call methods, which can be really costly on modern CPUs), make object themselves smaller. > > Would implementing them that way break D code ? What would be the extent of the breakage ? It could, but we don't have a stable ABI and we don't allow directly casting from interface references to classes. I would be interested to see how the performance changes on some interface-heavy D code - and honestly without an implementation that shows a big speed bump I don't think this will ever happen.

"Walter Bright" wrote in message news:lh83dr$6m1$1@digitalmars.com... > On 3/29/2014 8:26 PM, Daniel Murphy wrote: > > It could, but we don't have a stable ABI > > ? The ABI for interfaces hasn't changed in many years. In fact I don't even remember changes in it. I meant stable in the sense that we _can't_ break it, not that we _haven't_ broken it recently. ie we don't guarantee binary compatibility across releases.