Any usable SIMD implementation?

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Tue Apr 5 02:03:50 PDT 2016


On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote:
> On 4/4/2016 11:10 PM, 9il wrote:
>> It is impossible to deduct from that combination that Xeon Phi 
>> has 32 FP registers.
>
> Since dmd doesn't generate specific code for a Xeon Phi, having 
> a compile time switch for it is meaningless.
>
>
>> "Since the compiler never generates AVX or AVX2" - this is 
>> definitely nor true,
>> see, for example, LLVM vectorization and SLP vectorization.
>
> dmd is not LLVM.

The particular design and limitations of the dmd backend 
shouldn't be used to define D. In the extreme, your argument 
would imply that there's no point having version(ARM) built in to 
the language, because dmd doesn't support it.


>>> It's entirely practical to compile code with different source 
>>> code, link them
>>> *both* into the executable, and switch between them based on 
>>> runtime detection
>>> of the CPU.
>> This approach is complex,
>
> Not at all. Used to do it all the time in the DOS world (FPU vs 
> emulation).
>
>
>> I just want an unified instrument to receive CT information 
>> about target and
>> optimization switches. It is OK if this information would have 
>> different
>> switches on different compilers.
>
> Optimizations simply do not transfer from one compiler to 
> another, whether the switch is the same or not. They are highly 
> implementation dependent.
>
>
>> Auto vectorization is only example (maybe bad). I would use 
>> SIMD vectors, but I
>> need CT information about target CPU, because it is impossible 
>> to build optimal
>> BLAS kernels without it!
>
> I still don't understand why you cannot just set '-version=xxx' 
> on the command line and then switch off that version in your 
> custom code.

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.


More information about the Digitalmars-d mailing list