std.simd module

[Martin Nowak]

Am 05.02.2012, 02:46 Uhr, schrieb Manu <turkeyman at gmail.com>:

> On 5 February 2012 03:37, Martin Nowak <dawg at dawgfoto.de> wrote:
>
>> Am 05.02.2012, 02:13 Uhr, schrieb Manu <turkeyman at gmail.com>:
>>
>>
>>  On 5 February 2012 03:08, Martin Nowak <dawg at dawgfoto.de> wrote:
>>>
>>>  Let me restate the main point.
>>>> Your approach to a higher level module wraps intrinsics with named
>>>> functions.
>>>> There is little gain in making simd(AND, f, f2) to and(f, f2) when you
>>>> can
>>>> easily take this to the level GLSL achieves.
>>>>
>>>>
>>> What is missing to reach that level in your opinion? I think I  
>>> basically
>>> offer that (with some more work)
>>> It's not clear to me what you object to...
>>> I'm not prohibiting the operators, just adding the explicit functions,
>>> which may be more efficient in certain cases (they receive the  
>>> version).
>>>
>>> Also the 'gains' of wrapping an intrinsic in an almost identical  
>>> function
>>> are, portability, and potential optimisation for hardware versioning.  
>>> I'm
>>> specifically trying to build something that's barely above the  
>>> intrinsics
>>> here, although a lot of the more arcane intrinsics are being collated  
>>> into
>>> their typically useful functionality.
>>>
>>> Are you just focused on the primitive math ops, or something broader?
>>>
>>
>> GLSL achieves very clear and simple to write construction and conversion
>> of values.
>>
>> I think wrapping the core.simd vector types in an alias this struct  
>> makes
>> it a snap
>> to define conversion through constructors and swizzling through
>> properties/opDispatch.
>> Then you can overload operands to do the implementation specific stuff  
>> and
>> add named methods
>> for the rest.
>>
>
> So you are referring to the light wrapper class, that's what I thought.
> I think that's overcooking it a bit. Also, you seem to have ignored the
> reason I created the primitive operator functions twice now. They are
> needed to take advantage of the hardware with respect to different  
> versions.
No, I do see you point, but you can do it in the private part
of you module as well as in a vector struct as well as in a different  
module.

IMHO it's just a too shallow layer over intrinsics to make a useful phobos  
module.
In fact it's more low level for arithmetic operations than what dmd can  
already do for SSE vectors.

OTOH dot is very good as it is.

> At the lowest level, I am generally favouring performance over usage (if  
> it
> doesn't cause serious damage to the API).
> You're suggesting exactly what I expected half the forum to suggest, and
> I'm not against it in any way, but I think it's a layer above this. This
> should remain pure, and performance orientated...
> There must be a library that provides the opportunity for the best
> performance, before sugary libs get all layered over the top, and it's as
> I've said twice now, everyone will have a different idea of what that  
> sugar
> API will look like, so I feel it should live above this... or perhaps
> beside this (in the same file?), but I wouldn't want to remove this API  
> in
> favour of a vector 'class'.

A lot of people will be happy to use off the shelf primitives.