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.
