std.simd module

[Timon Gehr]

On 02/04/2012 08:57 PM, Manu wrote:
> So I've been trying to collate a sensible framework for a standard
> cross-platform simd module since Walter added the SIMD stuff.
> I'm sure everyone will have a million opinions on this, so I've drawn my
> approach up to a point where it properly conveys the intent, and I've
> proven the code gen works, and is good. Now I figure I should get
> everyone to shoot it down before I commit to the tedious work filling in
> all the remaining blanks.
>
> (Note: I've only written code against GDC as yet, since DMD's SSE only
> supports x64, and x64 is not supported in Windows)
> https://github.com/TurkeyMan/phobos/blob/master/std/simd.d
>
> The code might surprise a lot of people... so I'll give a few words
> about the approach.
>
> The key goal here is to provide the lowest level USEFUL set of
> functions, all the basic functions that people actually use in their
> algorithms, without requiring them to understand the quirks of various
> platforms vector hardware.
> Different SIMD hardware tends to have very different shuffling,
> load/store, component addressing, support for more/less of the primitive
> maths operations, etc.
> This library, which is the lowest level library I expect programmers
> would ever want to use in their apps, should provide that API at the
> lowest useful level.
>
> 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.
>
> 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.
>
> My key concern is with my function names... should I be worried about
> name collisions in such a low level lib? I already shadow a lot of
> standard float functions...

That is not really an issue. If it actually bothers someone, static or 
named imports come to the rescue.

> I prefer them abbreviated in this (fairly standard) way, keeps lines of
> code short and compact. It should be particularly familiar to anyone who
> has written shaders and such.

I agree.

>
> Opinions? Shall I continue as planned?

Looks good. I think it should provide emulation in case of non-existent 
hardware support (maybe even with a possibility to opt-out).