Hacker News Reader

Comment by marklacey | Hacker News Reader

I only barely skimmed the post and the follow-on posts so this is less about that and more about autovectorizers.

Autovectorization is the wrong approach for data-parallelization. You don’t want to rely on a brittle unpredictable code transformation for performance in this case. You want to bake it into the programming model.

ispc uses this approach and it results in performance predictability to a large degree. You can imagine other approaches as well, like explicitly data-parallel loops, or a declarative approach.

Most of these (and the GPU data-parallel models) rely to a very large extent on the programmer to manage data dependencies to ensure correctness.

View on HN

> You don’t want to rely on a brittle unpredictable code transformation for performance in this case.

That's somewhat true, but much of the unpredictability could be removed if compilers provided annotations saying "I expect this loop to be vectorized" where the compiler would be forced to report an error if it didn't manage to do it.

Such annotations exist in all major C/C++/Fortran compilers, although not all will error if it goes poorly. Although most of the ones with an HPC focus have some output where they will tell you how they optimized your loop for you.

> although not all will error if it goes poorly

So... these annotations don't actually exist? ;)

The whole point of such a feature is that the compiler will fail if it can't do what you want.

Well, it will not error out, but if you say

   #pragma clang loop vectorize(enable)

and the loop is then not vectorized you will get a warning like

   warning: loop not vectorized: failed explicitly specified loop vectorization

And then what do you do when you upgrade compilers and the build starts failing?

This isn’t a hypothetical, it happens in real life. Your only option at that point is roll back compilers and hope someone cares about the regression enough to fix it.

The point is the better model is to build the semantics into the language rather than relying on the whims of implementation.

Of course the semantic guarantees will likely be somewhat weak because of differences in ISAs, memory hierarchies, etc.

As fallback, I have unit-tests with a check on both correctness and the instruction count (and # of memory allocations in hot loops). Whereas the cpu cycle-count varies between runs, the instruction count does not.

Linux has good support for performance counters, Windows requires a bit of work.

So in this case, the compiler update would show a regression in the test suite, which needs to be addressed as part of the compiler upgrade.

Of course, having this in the compiler would remove the need for unit tests.

Just for the record: you rely on performance tests to guarantee performance, nothing else.

Reply on news.ycombinator.com