OOP, faster data layouts, compilers

[Peter Alexander]

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?

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?

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.