std.simd

[James Miller]

On 16 March 2012 08:02, Manu <turkeyman at gmail.com> wrote:
> On 15 March 2012 20:35, Robert Jacques <sandford at jhu.edu> wrote:
>> This sounds reasonable. However, please realize that if you wish to use
>> the short vector names (i.e. float4, float3, float2, etc) you should support
>> the full set with a decent range of operations and methods. Several people
>> (myself included) have written similar short vector libraries; I think
>> having having short vectors in phobos is important, but having one library
>> provide float4 and another float2 is less than ideal, even if not all of the
>> types could leverage the SMID backend. For myself, the killer feature for
>> such a library would be have the CUDA compatible alignments for the types.
>> (or an equivalent enum to the effect)
>
>
> I can see how you come to that conclusion, but I generally feel that that's
> a problem for a higher layer of library.
> I really feel it's important to keep std.simd STRICTLY about the hardware
> simd operations, only implementing what the hardware can express
> efficiently, and not trying to emulate anything else. In some areas I feel
> I've already violated that premise, by adding some functions to make good
> use of something that NEON/VMX can express in a single opcode, but takes SSE
> 2-3. I don't want to push that bar, otherwise the user will lose confidence
> that the functions in std.simd will actually work efficiently on any given
> hardware.
> It's not a do-everything library, it's a hardware SIMD abstraction, and most
> functions map to exactly one hardware opcode. I expect most people will want
> to implement their own higher level lib on top tbh; almost nobody will ever
> agree on what the perfect maths library should look like, and it's also
> context specific.

I think that having the low-level vectors makes sense. Since
technically only float4, int4, short8, byte16, actually make sense in
the context of direct SIMD, providing other vectors would be straying
into vector-library territory, as people would then expect
interoperability between them, standard vector/matrix operations, and
that could get too high-level. Third-party libraries have to be useful
for something!

Slightly off topic questions:
Are you planning on providing a way to fallback if certain operations
aren't supported? Even if it can only be picked at compile time? Is
your work on Github or something? I wouldn't mind having a peek, since
this stuff interests me. How well does this stuff inline? I can
imagine that a lot of the benefit of using SIMD would be lost if every
SIMD instruction ends up wrapped in 3-4 more instructions, especially
if you need to do consecutive operations on the same data.

--
James Miller