SIMD support...

[Manu]

I have to go to bed, so I'll leave these thoughts here... I apologise if I
misunderstood your suggestion.

These comments lead me to suspect you're talking again about vectors as
special cased arrays:

On 6 January 2012 04:40, Iain Buclaw <ibuclaw at ubuntu.com> wrote:

> * vector size cannot be zero
> * vector size must be a power of 2.
> * if there is no hardware support for the vector type/size, then fall
> back to static array type of same size.
> * defining a vector without a size ie: vint foo;  will default the
> size to zero, which will error.
>

The idea that you're talking about the possibility of arbitrary sizes
suggests you must be proposing array syntax?

See, again, I think this is precisely what NOT to do.
There are so many problems with this it's not funny, not least of all that
a user who doesn't examine the disassembly would have no idea if their code
is actually working or not.

As I've said above, I think vectors as arrays is the worst idea possible:
  * How do I declare an ARRAY now that we've hijacked the syntax?
  * You can't index SIMD components! exposing them with array syntax
encourages indexing, scalar access, usage in loops, etc. The API can't
permit that.
  * It's not clear that an array needs to be aligned any further than a
single component.
  * how do you do comparisons? what does your if statement look like? ... I
can tell you what people will do... if( v[0] > 0 && v[1] > 0 && v[1] < 10
&& v[2] > 0 ) ... This is not possible for the hardware, and shouldn't be
possible syntactically.
  * SIMD values can't interact with their scalar counterparts.. they live
in different register types, and there is no path between these registers
other than via memory... welcome to redundant memory access and LHS hazard
central.
  * You have absolutely no idea if the compiler is generating good code or
not... A more strict and formalised API will give confidence that it's
working correctly.

I promise you, as soon as you allow this, hidden costs of hitting memory
while transferring values back and forwards between SIMD and scalar
register types, and attempts at performing operations the hardware can not
actually perform will result in code that's slower than not using the SIMD
unit at all.
SIMD usage is an all or nothing thing, you can't sprinkle it in here and
there... the moment you start interacting with the scalar registers and
introducing redundant memory accesses, you've wasted more time in thrashing
the stack than you will gain from your failed attempt at optimisation.

SIMD needs to be implemented with a discreet type, which asserts it's
concept as a unique type of register, just as primitive in its own right as
'int', and encourage proper use through the carefully crafted APIs provided.
What I described is the very best way to get the best performance and type
safety from a SIMD unit, and encourage users to use the hardware
correctly...
I promise... I've written so many SIMD vector libraries over the years now.

Here's a silly analogy...
You don't go casting back and fourth between int and float liberally just
for the sake of it... You just don't do that. You know the cost, and other
issues involved and avoid it like the plague, only doing it in the
extremely rare case that you absolutely have to. And when you do, you do it
deliberately, and probably contemplate ways to avoid doing so before you
submit to it...
SIMD operations are no different, except the costs involved in
intercommunication are much bigger than int<->float. You need to have the
mentality that they're on separate planets. Exposing SIMD like it's an
array of some other primitive type completely goes against that sentiment,
and fosters the wrong idea of what SIMD math is to users. They'll try it
out, and wonder why it doesn't make their program any faster (probably
slower actually)...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120106/56883007/attachment.html>