std.simd

[Manu]

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'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120316/59f27fde/attachment.html>