std.simd module

[Manu]

On 5 February 2012 02:17, Martin Nowak <dawg at dawgfoto.de> wrote:

> First criticism I expect is for many to insist on a class-style vector
>> library, which I personally think has no place as a low level, portable
>> API.
>> Everyone has a different idea of what the perfect vector lib should look
>> like, and it tends to change significantly with respect to its
>> application.
>>
>>
>  - Thing like toDouble, toFloat don't map to vectors if they change the
> number of elements.
>

You'll notice my comment above those functions, I refer that this is a
perfect opportunity for multiple return values, and short of that, maybe
I'll remove the functions, or change them in some way.

 - What's getX(byte16), swizzling makes sense for float4/double2, not sure
> about the rest.
>

I agree that's not clear, I had intended to add some asserts limiting those
to 2-4d vectors, or actually change the names of those functions completely.
They really just call through to a broadcast swizzle!().

 - Using named free functions for operands (or, complement, neg) is overly
> verbose.
>

Is it possible to implement global operators like this? I think it's
important to keep the functions there for those anyway... it offers
explicit versioning, and some architectures may have non trivial
implementations for those functions (for instance, neg requires 0-x on some
hardware)

The operators are still supported if you prefer to use them, obviously.

So indeed my proposal is to prefer GLSL-like syntax.
>
> // construction conversion
> auto f   = float4(1.0, 2.0f, 3, 4);
> auto f2  = v.yxzw;                         // using opDispatch
>

I planed to do this, but so far I've spent a lot of time with swizzle!().
Getting that right is tricky, and that's the meat of all permutation
operations. Everything else will be layers of prettiness over that.

auto d   = double2(v.wy);
> auto d   = double2(v.get!(0), v.get!(1));  // probably someone knows a
> trick for compile time indexing (v[0])
>

swizzle!() already does this work (compile time), I'll be wrapping more
handy helpers around that when it's complete.

auto f3  = float4(1.0, d, 2);
> double d = f3.z;
>

This API will never offer this operation. It is the single worst violation
of the API, and the fastest way to make the whole implementation pointless.
Swapping register types is often the worst hazard a CPU is capable of.

Casting to scalar will only be implemented with explicit functions, and
performance hazards detailed in the documentation, which hopefully people
will read, since they'll need to look up the function to use it ;)

// a lot of operands can be mapped and are already
> f |= f2;
> f  = f & ~f2;
>

Sure, what's your point? You'll see I use them all over the place.
That said, encouraging usage of functions like andn() in this case will
result in an optimisation on some hardware which the compiler is probably
not capable of without specific tweaking by someone who knows what they're
doing.
It's really bad form to depend on an optimiser to fix my code, when you
could have just given it the appropriate instruction right up front.
Especially true for an open source project like D where contributions of
that sort are unreliable, and the number of people qualified to improve the
optimiser in that way are very low.

I feel this flat API is easier to implement, maintain, and understand, and
>> I expect the most common use of this lib will be in the back end of
>> peoples
>> own vector/matrix/linear algebra libs that suit their apps.
>>
>>  Phobos should provide at least basic vector and matrix implementations.
>

It will, but that's a separate (higher level) module, although this
provides most foundational vector operations.
I want to keep this level primitive and simple. If there's any dispute over
the implementation of this layer, just imagine the dispute when trying to
implement matrix and quaternion libs... they can be so context specific.
Consider the differences between realtime and scientific uses... This
library can't really go wrong at that level, but there's a LOT more to
consider when working on that layer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120205/fc1968af/attachment.html>