std.simd module

Manu turkeyman at gmail.com
Sat Feb 4 16:37:35 PST 2012


On 5 February 2012 01:35, Timon Gehr <timon.gehr at gmx.ch> wrote:

> 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<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).
>

It will, although I'm still not clear on how far to take that... in some
cases, simply not supporting the feature for their hardware encourages them
to implement a different solution, which they should do on such a system.
I also intend to support float[N] for those systems with no vector
hardware. It's important to the API that float[4] and native vectors are
not implicitly interchangeable though, this is a major performance hazard
which the API should not encourage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120205/4172b286/attachment.html>


More information about the Digitalmars-d mailing list