On Fri, 16 Mar 2012 16:45:05 -0500, Manu <[email protected]> wrote:
On 16 March 2012 22:39, Robert Jacques <[email protected]> wrote:
On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <[email protected]>
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.
