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

[Manu]

On 30 March 2014 13:39, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 3/29/2014 8:06 PM, deadalnix wrote:
>
>> On Sunday, 30 March 2014 at 01:42:24 UTC, Walter Bright wrote:
>>
>>> True, but why is this a problem?
>>>
>> Higher memory consumption, less objects fitting in cache, more scanning
>> to do
>> for the GC.
>>
>
> Debatable. All fields that are interface references would double in size.
>
>
>
>  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.
>>
>
> That underestimates how precious register real estate is on the x86.


This is only a concern when passing args. x86 has huge internal register
files and uses aggressive register renaming, for the last decade or so.
The only time when the number of named registers is significant these days
is the fastcall calling convention (standard on x64), since functions need
to expect it's arg in an explicitly named register.
x64 doubled the number of argument registers to help with this (still fewer
than other arch's).

 On the other hand, the double indirection is very cache unfriendly.
>>
>
> I suspect that the results of all this will be some use cases go faster,
> other use cases go slower, a decidedly mixed result.
>

The most interesting result of the change for me would be that it wouldn't
break alignment.
But wrt performance, in my experience, i'm frequently worried about the
indirection and potential cache miss. I can't imagine I'd often be so
concerned about using an additional arg register. And that's more easily
mitigated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140331/377061a2/attachment.html>