On 30 March 2014 13:39, Walter Bright <newshound2@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.