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++.

Swift as a general cross-platform replacement is mostly out unless Apple takes over the world or makes some un-Apple-like shift to embrace and support other platforms.

Go isn't really an exact match for most systems programming or HPC due to garbage collection and the need for a "runtime". It could displace C++ from other areas like "code that just needs to be fairly fast", like various services and servers: but most of those people have already left (largely to Java if they left a while ago, or to a mix of languages, including Go, if more recently).

I see Rust as the language most likely to displace most C++ over the long term. Mostly "by default" since it is the only language with widespread adoption and cross-platform support that compiles down to native in the same way as C++. People who don't need that feature have in many cases already moved on or will move on in the future (there are many alternatives already in this area).

>

> #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).


> LLVM is so much better than the alternatives I do not see why you would use any other compiler.

LLVM has accelerated enormously in the last 5 or 10 years and it often produces better code, but gcc and icc are both still competitive. For auto-vectorization it is not my experience that LLVM is strictly better.

In any case it's a moot point unless you can restrict your software to a single compiler (but if you can, LLVM is a fine choice).


> C++ is too pathetic to ever auto-vectorize, you have to use
> #pragma’s to tell the compiler what to do. Period.

I almost automatically disagree with such an absolute statement, but sure the pragmas are nice for tuning.

It's probably a bit like inline - when compilers had terrible or zero heuristics for inlining, this keyword was really important and you had better learn to use it. Eventually the heuristics improved a lot and now the conventional wisdom is "don't even both, the compiler is smarter that you can will inline what it wants" which although probably a swing too far in the other direction is probably reasonable advice for most code.

Because the auto-vectorized code is often applied inappropriately today, these pragams have an outsized important. Maybe when the heuristics get better you won't need them as much (but as I mentioned the problem is harder than inlining in a lot of ways since the compiler doesn't have critical information like loop counts, typical alignment, etc).


> Eventually a real language will add autovectorization and people will dump C++.

I doubt that will be the tipping point. Many people have already dumped C++, and the people who are still there (including me for many projects) are certainly not waiting for auto-vectorization to appear as the killer feature in some other language.

I'm pretty sure other languages already have it too, especially those using LLVM as their backend? Rust probably has it? Java has it.