Travis (travis.downs.delete@this.gmail.com) on August 4, 2018 2:38 pm wrote:
> Brett (ggtgp.delete@this.yahoo.com) on August 4, 2018 1:55 pm wrote:
> > C++ is a total dead end.
> > I would recommend a real language like Swift or Go instead, but autovectorization is not available yet.
>
> I don't think anyone knowledgeable would call C++ not a "real" language. If anything,
> it is too real: the complexity implied by the language itself, principles like "zero-cost
> abstractions" and then the various features added over 30+ years with last couple decades
> being "by committee" is incredible and daunting to any newcomer.
>
> I doubt Swift or Go will ever replace C++.

Specifically for autovectorization, I don't know of any advantage Swift, Go, or Rust inherently have over C++; they all share the same issue that everyone uses imperative loops. They could add loops with more relaxed ordering constraints to ease autovectorization, but C++17 already has those with parallel_vector_execution_policy...

> > #pragma clang loop vectorize(enable)
> > #pragma clang loop vectorize_width(2) interleave_count(2)
> >
> > And a long list of variants for loops so that you do not have to write assembly.
> > https://llvm.org/docs/Vectorizers.html
>
> What's your point? Do you think people writing BLAS kernels
> or media codecs or whatever are using these widely?
>
> Sure they are useful, just like any other hints you can provide to the compiler, but they
> don't change the basic equation of auto-vectorization. In particular, they don't automatically
> make the vectorizer smarter (except that you can fix some parameters like width).

These pragmas also specify that the order of execution within each loop iteration is undefined with respect to other loop iterations (or only sequenced after N iterations, or whatever), which is a basic requirement to even consider vectorizing a loop. A compiler sufficiently smart to infer that for most loops still doesn't exist... So you could consider these pragmas as a weak form of explicit vectorization, I guess.

Also, OpenMP standardized these pragmas across the major compiler vendors, so if you use theirs it's not like you're completely locked into a single compiler. As far as wanting to use them, well, I've got some larger loops with complex control flow that I expect would gain from AVX-512's predication. They're complex enough that I don't want to re-write them in intrinsics (:effort: and I suspect the predication would make a near-unreadable mess, especially pre-AVX512.)

Buuut... yeah, it's still really easy for clang's vectorizer to throw its hands up at nonstandard control flow, even where I'd expect similar code to remain vectorized in GPU compilers. Oh well...