OOP, faster data layouts, compilers

[Don]

Peter Alexander wrote:
> On 26/04/11 9:01 AM, Don wrote:
>> Sean Cavanaugh wrote:
>>> In many ways the biggest thing I use regularly in game development
>>> that I would lose by moving to D would be good built-in SIMD support.
>>> <snip>
>>
>> Yes. It is for primarily for this reason that we made static arrays
>> return-by-value. It is intended that on x86, float[4] will be an SSE1
>> register.
>> So it should be possible to write SIMD code with standard array
>> operations. (Note that this is *much* easier for the compiler, than
>> trying to vectorize scalar code).
>>
>> This gives syntax like:
>> float[4] a, b, c;
>> a[] += b[] * c[];
>> (currently works, but doesn't use SSE, so has dismal performance).
> 
> What about float[4]s that are part of an object? Will they be 
> automatically align(16) so that they can be quickly moved into the SSE 
> registers, or will the user have to specify that manually?

No special treatment, they just use the alignment for arrays of the 
type. Which I believe is indeed align(16) in that case.

> Also, what if I don't want my float[4] to be stored in a SSE register 
> e.g. because I will be treating those four floats as individual floats, 
> and never as a vector?

That's a decision for the compiler to make. It'll generate whatever code 
it thinks is appropriate. (My mention of float[4] being in an SSE 
register applies ONLY to parameter passing; but it isn't decided yet 
anyway).

> IMO, float[4] should be left as it is and you should introduce a new 
> vector data type that has all these optimisations. Just because a vector 
> is four floats doesn't mean that all groups of four floats are vectors.

It has absolutely nothing to do with vectors. All groups of floats (of 
ANY length) benefit from SIMD. D's semantics make it easy to take 
advantage of SIMD, regardless of what size it is.

C's ancient machine model doesn't envisage SIMD, so C compilers are left 
with a massive abstraction inversion. It's really quite ridiculous that 
in this area, most mainstream programming languages are still operating 
at a lower level of abstraction than asm.