std.simd

[Manu]

On 15 March 2012 20:35, Robert Jacques <sandford at jhu.edu> wrote:

> On Thu, 15 Mar 2012 12:09:58 -0500, Manu <turkeyman at gmail.com> wrote:
>
>> Hey chaps (and possibly lasses?)
>>
>> I've been slowly working a std.simd library, the aim of which is to
>> provide
>> a lowest-level hardware-independent SIMD interface. core.simd implements
>> SSE currently for x86, other architectures are currently exposed via
>> gcc.builtins.
>> The purpose of std.simd, is to be the lowest level API that people make
>> direct use of, while still having as-close-to-direct-as-possible mapping
>> to
>> the hardware opcodes, but still being portable. I would expect that
>> custom,
>> more-feature-rich SIMD/vector/matrix/linear algebra libraries should be
>> built on top of std.simd in future, that way being portable to as many
>> systems as possible.
>>
>> Now I've reached a question in the design of the library, I'd like to take
>> a general consensus.
>>
>> lowest level vectors are defined by: __vector(type[width])
>> But core.simd also defines a bunch of handy 'nice' aliases for common
>> vector types, ie, float4, int4, short8, etc.
>>
>> I want to claim those names into std.simd. They should be the lowest level
>> names that people use, and therefore associate with the std.simd
>> functionality.
>> I also want to enhance them a bit:
>>  I want to make them a struct that wraps the primitive rather than an
>> alias. I understand this single-POD struct will be handled the same as the
>> POD its self, is that right? If I pass the wrapper struct byval to a
>> function, it will be passed in a register as it should yeah?
>>  I then intend to then add CTFE support, and maybe some properties and
>> opDisplatch bits.
>>
>> Does this sound reasonable?
>>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120315/29af7560/attachment.html>