Any usable SIMD implementation?

[Walter Bright via Digitalmars-d]

On 4/5/2016 2:03 AM, John Colvin wrote:
> So you're suggesting that libraries invent their own list of versions for
> specific architectures / CPU features, which the user then has to specify
> somehow on the command line?
> I want to be able to write code that uses standardised versions that work across
> various D compilers, with the user only needing to type e.g. -march=native on
> GDC and get the fastest possible code.

There's a line between trying to standardize everything and letting add-on 
libraries be free to innovate.

Besides, I think it's a poor design to customize the app for only one SIMD type. 
A better idea (I've repeated this ad nauseum over the years) is to have n 
modules, one for each supported SIMD type. Compile and link all of them in, then 
detect the SIMD type at runtime and call the corresponding module. (This is how 
the D array ops are currently implemented.)

My experience with command line FPU switches is few users understand what they 
do and even fewer use them correctly.

In fact, I suspect that having a command line FPU switch is too global a hammer. 
A pragma set in just the functions that need it might be much better.

-------

In any case, this is not a blocker for getting the library designed, built and 
debugged.