std.simd

[Robert Jacques]

On Fri, 16 Mar 2012 16:45:05 -0500, Manu <turkeyman at gmail.com> wrote:
> On 16 March 2012 22:39, Robert Jacques <sandford at jhu.edu> wrote:
>> On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see at klickverbot.at>
>> wrote:
>>  On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:

[snip]

>> Unrelated libraries using the same name is relatively painless. Highly
>> related libraries that conflict, on the other hand, are generally painful.
>> Yes, there are a lot of mechanisms available to work around this, but
>> selective imports and renaming all add to the cognitive load of using and
>> writing the code.
>>
>> To me float4 isn't a SIMD name; its a vector name and if it's implemented
>> using SIMD, great, but that's an implementation detail. I can understand a
>> close to the metal SIMD library and encourage the work. But if it isn't
>> also going to be a vector library, if possible, it shouldn't use the vector
>> names.
>>
>
> Can you give me an example of a non-simd context where this is the case?
> Don't say shaders, because that is supported in hardware, and that's my
> point.
> Also there's nothing stopping a secondary library adding/emulating the
> additional types. They could work seamlessly together. flaot4 may come from
> std.simd, float3/float2 may be added by a further lib that simply extends
> std.simd.

Shaders. :) Actually, float4 isn't supported in hardware if you're on NVIDIA. And IIRC ATI/AMD is moving away from hardware support as well. I'm not sure what Intel or the embedded GPUs do. On the CPU side SIMD support on both ARM and PowerPC is optional. As for examples, pretty much every graphics, vision, imaging and robotics library has a small vector library attached to it; were you looking for something else?

Also, clean support for float3 / float2 / etc. has shown up in Intel's Larrabee and its Knight's derivatives; so, maybe we'll see it in a desktop processor someday. To say nothing of the 245-bit and 512-bit SIMD units on some machines.

My concern is that std.simd is (for good reason) leaking the underlying hardware implementation (std.simd seems to be very x86 centric), while vectors, in my mind, are a higher level abstraction.