Ready for review: new std.uni

David Nadlinger see at klickverbot.at
Mon Jan 14 00:28:48 PST 2013


On Monday, 14 January 2013 at 07:21:57 UTC, Walter Bright wrote:
> I've done some research on auto-vectorization, i.e. "The 
> Software Vectorization Handbook" by Bik.
>
> My conclusion (Manu independently came to the same one, he's 
> our resident SIMD expert) is that auto-vectorization is a 
> disaster.
>
> What it is is:
>
> 1. Reverse engineer a loop into a higher level construct
> 2. Recompile that construct using vector instructions
>
> It's a disaster because (2) often fails in ways that are 
> utterly mysterious to 99% of programmers. The failure mode is 
> to not auto-vectorize the loop. Hence, the failure is silent 
> and the user just sees poor performance, if he notices it at 
> all.

Virtually all common C/C++ compilers have had SIMD 
types/intrinsics for years now, which is more or less exactly 
what core.simd is for D - well, there is some syntax sugar for 
arithmetic operations on the D vector types, but it doesn't cover 
any of the "interesting" operations such as broadcasting, 
swizzling, etc.

Yet *all* the big compiler vendors (Microsoft, Intel, GCC, LLVM) 
seem to find it necessary to spend considerable amounts of effort 
on improving their heuristics for the indeed quite problematic 
optimization process you describe.

I don't think that rehashing the common reasons cited for the 
importance of (auto-)vectorizing code here would be of any use, 
you are certainly aware of them already. Just don't forget that 
Manu (who seems to have disappeared from the forums, crunch 
time?) represents a group of programmers who would resort to 
hand-written assembly for their "embarrassingly parallel" code if 
suitable compiler intrinsics didn't exist, whereas the vast 
majority of programmers probably would be troubled to reliably 
identify the cases where vectorization would have the biggest 
benefits in their code bases, even if they could justify spending 
time/maintainability on manually optimizing their code at this 
level.

David


More information about the Digitalmars-d mailing list