8

As I understand, most modern compilers automatically use SIMD instructions for loops where appropriate, if I set the corresponding compiler flag. Since the compiler can only use vectorization if it can be sure that doing so will not change the semantics of the program, it will not use vectorizations in cases where I actually know it's be safe, but the compiler for various reasons thinks its not.

Are there explicit vectorization instructions that I can use in plain C++ without libraries, which let me process vectorized data myself instead of relying on the compiler? I imagine it will look something like this:

double* dest;
const double* src1, src2;
// ...
for (uint32 i = 0; i < n; i += vectorization_size / sizeof(double))
{
    vectorized_add(&dest[i], &src1[i], &src2[i]);
}
Micheal Bays
  • 83
  • 4
  • 1
    What about writing your code so that the compiler can tell that it is safe? – Bo Persson Sep 15 '15 at 17:39
  • AFAIK, there is nothing in the "standard C++" about these options. But I guess that there are "proprietary" options/instructions in both, Microsoft C++ and GCC/Clang that will do exactly that. – user23573 Sep 15 '15 at 17:41
  • There's currently nothing in standard C++ for this, although there has been some discussion in the standards committee. Currently you need to use the intrinsics provided by your platform which are not portable across CPU architectures and are only somewhat portable between compilers. – mattnewport Sep 15 '15 at 17:50
  • related: http://stackoverflow.com/questions/29292818/how-to-vectorize-my-loop-with-g – NathanOliver Sep 15 '15 at 17:53

2 Answers2

4

Plain C++? No. std::valarray can lead your compiler to the SIMD water, but it can't make it drink.

OpenMP is the least "library" library out there: it's more of a language extension than a library, and all major C++ compilers support it. While primarily and historically used for multicore parallelism, OpenMP 4.0 introduced SIMD-specific constructs which can at least urge your compiler to vectorize certain clearly-vectorizable procedures, even ones with apparently scalar subroutines. It can also help you identify aspects of your code which are preventing the compiler from vectorizing. (And besides... don't you want multicore parallelism too?)

double* dest;
const double* src1, src2;

#pragma omp simd
for (int i = 0; i < n; i++)
{
    dest[i] = src1[i] + src2[i];
}

To go the last mile with reduced-precision operations, multilane aggregation, branch-free masking, etc. really requires an explicit connection to the underlying instruction set, and isn't possible with anything close to "plain C++". OpenMP can get you pretty far, though.

Sneftel
  • 40,271
  • 12
  • 71
  • 104
2

TL;DR No guarantees, but KISS and you are likely to get highly optimized code. Measure and inspect the generated code before tinkering with it.

You can play with this on online compilers, e.g. gcc.godbolt will vectorize the following straightforward call to std::transform for gcc 5.2 with -O3 

#include <algorithm>

const int sz = 1024;

void f(double* src1, double* src2, double* dest)
{
    std::transform(src1 + 0, src1 + sz, src2, dest, 
        [](double lhs, double rhs){
        return lhs + rhs;
    });    
}

There was a similar Q&A earlier this week. The general theme seems to be that on modern processors and compilers, the more straightforward your code (plain algorithm calls), the more likely you'll get highly optimized (vectorized, unrolled) code.

Community
  • 1
  • 1
TemplateRex
  • 69,038
  • 19
  • 164
  • 304
  • This isn't vectorized. It's vectorized at -O3 though. – T.C. Sep 15 '15 at 19:26
  • The register used isn't significant. The instruction used is. `movsd` and `addsd` work on one double at a time. (Note that this code loops exactly 8192/8 = 1024 times; a vectorized loop would have fewer iterations.) – T.C. Sep 15 '15 at 19:32