std.simd

[Robert Jacques]

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)