On 15 March 2012 20:35, Robert Jacques <sandford@jhu.edu> wrote:
On Thu, 15 Mar 2012 12:09:58 -0500, Manu <turkeyman@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.