std.simd module

[Manu]

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.
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'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120205/593e7ebb/attachment.html>