std.simd module

Sean Cavanaugh WorksOnMyMachine at
Sat Feb 4 21:47:10 PST 2012

Looks good so far:

   it could use float[2] code wherever there is float[3] code 
(magnitude2 etc)

   any/all should have template overloads to let you specificy exactly 
which channels match, and simple hardcoded ones for the common cases 
(any1, any2, any3, any4 aka the default 'any')

   I have implementations of floor/ceil/round(to-even) that work on 
pre-SSE4 hardware for float and doubles I can give out they are fairly 
simple, as well as the main transcendentals (pow, exp, log, sin, cos, 
tan, asin, acos, atan).  sinh and cosh being the only major ones I left out.

I just need a place or address to post or mail the code.

   D should be able to handle names and overloading better, though 
giving everything unique names was the design choice I made for my 
library, primarily to make the code searchable and potentially portable 
to C (aside from the heavy use of const references as argument types).

On 2/4/2012 1: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)
> 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...
> 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.
> Opinions? Shall I continue as planned?

More information about the Digitalmars-d mailing list