Small Vectors Proposal

[janderson]

Knud Soerensen wrote:


> You can think at it as a SQL for vector operations.
> See http://all-technology.com/eigenpolls/dwishlist/index.php?it=10
> There is also a suggestion for a general form of Swizzle operations
> http://all-technology.com/eigenpolls/dwishlist/index.php?it=11
> 
> I think that you forget that a program using vectors typical use a lot 
> of them and therefor it needs to transform a lot at a time.
> 
> Exsample take a models using 1000 vectors.
> 
> Your suggestion would suggest defining it like 
> float3 model[1000].
> and it would suggest that they where placed in memory as
> x1 y1 z1
> x2 y2 z2
> x3 y3 z3
> .
> .
> .
> 
> each vector following each other.
> 
> But now imagine that the most used operation in the program 
> is a plan projection on the x-y plan, then we only need the x and y
> coordinate.
> So an arrangement in memory which looks like 
> x1 x2 x3 . . .
> y1 y2 y3 . . .
> z1 z2 z3 . . .
> would result in that the cpu could specific load only the x and the y
> coordinates into the cache, which would speed up the calculations a lot.
> 
> So, if one could specify that 3x1000 floats and let the compiler
> arrange them in memory that would be optimal.

I think this is a special case.  Typically I'd say the programmer would 
be applying operations on several component at a time.  The SIMD is 
setup this way.  Maybe the compiler could detect the case your taking 
about, however I think eventually the elements in the array would want 
to be used as components.

I do however think a long list of values (such as a vertex buffer) would 
gain from SIMD optimized operations (future hardware devices which will 
add more and more array support and parallelism).

 > I think it is better to make very general framework for describing the
 > vector operations, because when we have a very general description
 > then the compiler is free to optimize as it sees fit.

This I agree with.  The first versions need not provide SIMD 
optimizations they just need to be done in such a way that these can be 
added later without changing our code.  I can imagine situations in the 
future where were write for instance a multiply and then an add.  The 
compiler sees this (re-arrange code as it needs to) and change it to the 
SIMD muladd.  ie arrays become like just another numerical datatype the 
compiler can manipulate.

This sort of thing will help reduce micro-optimizations needed for this 
type of coding.

-Joel