On 16 March 2012 08:02, Manu <[email protected]> wrote: > On 15 March 2012 20:35, Robert Jacques <[email protected]> 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
