std.simd

[James Miller]

On 16 March 2012 11:44, Manu <turkeyman at gmail.com> wrote:
> On 15 March 2012 22:27, James Miller <james at aatch.net> wrote:
>>
>> 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?
>
>
> I think it depends on HOW unsupported they are. If it can be emulated
> efficiently (and in the context, the emulation would be as efficient as
> possible on the architecture anyway), then probably, but if it's a problem
> that should simply be solved another way, I'd rather encourage that with a
> compile error.
>
>> Even if it can only be picked at compile time? Is
>> your work on Github or something?
>
>
> Yup: https://github.com/TurkeyMan/phobos/commits/master/std/simd.d
>
>>
>> I wouldn't mind having a peek, since
>> this stuff interests me. How well does this stuff inline?
>
>
> It inlines perfectly, I pay very close attention to the codegen every single
> function. And have loads of static branches to select more efficient
> versions for more recent revisions of the SSE instruction set.
>
>>
>> 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.
>
>
> It will lose 100% of its benefit it it is wrapped up in even ONE function
> call, and equally so if the vectors don't pass/return in hardware registers
> as they should.
> I'm crafting it to have the same performance characteristics as 'int'.

Cool, thanks for answering my questions. Some of what I'm working on
atm would benefit from simd.

--
James Miller