Masking and Blending - Algorithmica

# Masking and Blending

One of the bigger challenges of SIMD programming is that its options for control flow are very limited — because the operations you apply to a vector are the same for all its elements.

This makes the problems that are usually trivially resolved with an if or any other type of branching much harder. With SIMD, they have to be dealt with by the means of various branchless programming techniques, which aren’t always that straightforward to apply.

### #Masking

The main way to make a computation branchless is through predication — computing the results of both branches and then using either some arithmetic trick or a special “conditional move” instruction:

for (int i = 0; i < N; i++)
a[i] = rand() % 100;

int s = 0;

// branch:
for (int i = 0; i < N; i++)
if (a[i] < 50)
s += a[i];

// no branch:
for (int i = 0; i < N; i++)
s += (a[i] < 50) * a[i];

// also no branch:
for (int i = 0; i < N; i++)
s += (a[i] < 50 ? a[i] : 0);


To vectorize this loop, we are going to need two new instructions:

• _mm256_cmpgt_epi32, which compares the integers in two vectors and produces a mask of all ones if the first element is more than the second and a mask of full zeros otherwise.
• _mm256_blendv_epi8, which blends (combines) the values of two vectors based on the provided mask.

By masking and blending the elements of a vector so that only the selected subset of them is affected by computation, we can perform predication in a manner similar to the conditional move:

const reg c = _mm256_set1_epi32(49);
const reg z = _mm256_setzero_si256();
reg s = _mm256_setzero_si256();

for (int i = 0; i < N; i += 8) {
reg x = _mm256_load_si256( (reg*) &a[i] );
reg mask = _mm256_cmpgt_epi32(x, c);
x = _mm256_blendv_epi8(x, z, mask);
s = _mm256_add_epi32(s, x);
}


(Minor details such as horizontal summation and accounting for the remainder of the array are omitted for brevity.)

This is how predication is usually done in SIMD, but it isn’t always the most optimal approach. We can use the fact that one of the blended values is zero, and use bitwise and with the mask instead of blending:

const reg c = _mm256_set1_epi32(50);
reg s = _mm256_setzero_si256();

for (int i = 0; i < N; i += 8) {
reg x = _mm256_load_si256( (reg*) &a[i] );
reg mask = _mm256_cmpgt_epi32(c, x);
x = _mm256_and_si256(x, mask);
s = _mm256_add_epi32(s, x);
}


This loop performs slightly faster because on this particular CPU, the vector and takes one cycle less than blend.

Several other instructions support masks as inputs, most notably:

• The _mm256_blend_epi32 intrinsic is a blend that takes an 8-bit integer mask instead of a vector (which is why it doesn’t have v at the end).
• The _mm256_maskload_epi32 and _mm256_maskstore_epi32 intrinsics that load/store a SIMD block from memory and and it with a mask in one go.

We can also use predication with built-in vector types:

vec *v = (vec*) a;
vec s = {};

for (int i = 0; i < N / 8; i++)
s += (v[i] < 50 ? v[i] : 0);


All these versions work at around 13 GFLOPS as this example is so simple that the compiler can vectorize the loop all by itself. Let’s move on to more complex examples that can’t be auto-vectorized.

### #Searching

In the next example, we need to find a specific value in an array and return its position (aka std::find):

const int N = (1<<12);
int a[N];

int find(int x) {
for (int i = 0; i < N; i++)
if (a[i] == x)
return i;
return -1;
}


To benchmark the find function, we fill the array with numbers from $0$ to $(N - 1)$ and then repeatedly search for a random element:

for (int i = 0; i < N; i++)
a[i] = i;

for (int t = 0; t < K; t++)
checksum ^= find(rand() % N);


The scalar version gives ~4 GFLOPS of performance. This number includes the elements we haven’t had to process, so divide this number by two in your head (the expected fraction of the elements we have to check).

To vectorize it, we need to compare a vector of its elements with the searched value for equality, producing a mask, and then somehow check if this mask is zero. If it isn’t, the needed element is somewhere within this block of 8.

To check if the mask is zero, we can use the _mm256_movemask_ps intrinsic, which takes the first bit of each 32-bit element in a vector and produces an 8-bit integer mask out of them. We can then check if this mask is non-zero — and if it is, also immediately get the index with the ctz instruction:

int find(int needle) {
reg x = _mm256_set1_epi32(needle);

for (int i = 0; i < N; i += 8) {
reg y = _mm256_load_si256( (reg*) &a[i] );
reg m = _mm256_cmpeq_epi32(x, y);
int mask = _mm256_movemask_ps((__m256) m);
if (mask != 0)
return i + __builtin_ctz(mask);
}

return -1;
}


This version gives ~20 GFLOPS or about 5 times faster than the scalar one. It only uses 3 instructions in the hot loop:

vpcmpeqd  ymm0, ymm1, YMMWORD PTR a[0+rdx*4]
vmovmskps eax, ymm0
test      eax, eax
je        loop


Checking if a vector is zero is a common operation, and there is an operation similar to test in SIMD that we can use:

int find(int needle) {
reg x = _mm256_set1_epi32(needle);

for (int i = 0; i < N; i += 8) {
reg y = _mm256_load_si256( (reg*) &a[i] );
reg m = _mm256_cmpeq_epi32(x, y);
if (!_mm256_testz_si256(m, m)) {
int mask = _mm256_movemask_ps((__m256) m);
return i + __builtin_ctz(mask);
}
}

return -1;
}


We are still using movemask to do ctz later, but the hot loop is now one instruction shorter:

vpcmpeqd ymm0, ymm1, YMMWORD PTR a[0+rdx*4]
vptest   ymm0, ymm0
je       loop


This doesn’t improve performance much because both both vptest and vmovmskps have a throughput of one and will bottleneck the computation regardless of anything else we do in the loop.

To work around this limitation, we can iterate in blocks of 16 elements and combine the results of independent comparisons of two 256-bit AVX2 registers using a bitwise or:

int find(int needle) {
reg x = _mm256_set1_epi32(needle);

for (int i = 0; i < N; i += 16) {
reg y1 = _mm256_load_si256( (reg*) &a[i] );
reg y2 = _mm256_load_si256( (reg*) &a[i + 8] );
reg m1 = _mm256_cmpeq_epi32(x, y1);
reg m2 = _mm256_cmpeq_epi32(x, y2);
reg m = _mm256_or_si256(m1, m2);
if (!_mm256_testz_si256(m, m)) {
int mask = (_mm256_movemask_ps((__m256) m2) << 8)
+  _mm256_movemask_ps((__m256) m1);
return i + __builtin_ctz(mask);
}
}

return -1;
}


With this obstacle removed, the performance now peaks at ~34 GFLOPS. But why not 40? Shouldn’t it be twice as fast?

Here is how one iteration of the loop looks in assembly:

vpcmpeqd ymm2, ymm1, YMMWORD PTR a[0+rdx*4]
vpcmpeqd ymm3, ymm1, YMMWORD PTR a[32+rdx*4]
vpor     ymm0, ymm3, ymm2
vptest   ymm0, ymm0
je       loop


Every iteration, we need to execute 5 instructions. While the throughputs of all relevant execution ports allow to do that in one cycle on average, we can’t do that because the decode width of this particular CPU (Zen 2) is 4. Therefore, the performance is limited by ⅘ of what it could have been.

To mitigate this, we can once again double the number of SIMD blocks we process on each iteration:

unsigned get_mask(reg m) {
return _mm256_movemask_ps((__m256) m);
}

reg cmp(reg x, int *p) {
reg y = _mm256_load_si256( (reg*) p );
return _mm256_cmpeq_epi32(x, y);
}

int find(int needle) {
reg x = _mm256_set1_epi32(needle);

for (int i = 0; i < N; i += 32) {
reg m1 = cmp(x, &a[i]);
reg m2 = cmp(x, &a[i + 8]);
reg m3 = cmp(x, &a[i + 16]);
reg m4 = cmp(x, &a[i + 24]);
reg m12 = _mm256_or_si256(m1, m2);
reg m34 = _mm256_or_si256(m3, m4);
reg m = _mm256_or_si256(m12, m34);
if (!_mm256_testz_si256(m, m)) {
unsigned mask = (get_mask(m4) << 24)
+ (get_mask(m3) << 16)
+ (get_mask(m2) << 8)
+  get_mask(m1);
return i + __builtin_ctz(mask);
}
}

return -1;
}


It now shows the throughput of 43 GFLOPS — or about 10x faster than the original scalar implementation.

Extending it to 64 values per cycle doesn’t help: small arrays suffer from the overhead of all these additional movemask-s when we hit the condition, and larger arrays are bottlenecked by memory bandwidth anyway.

### #Counting Values

As the final exercise, let’s find the count of a value in an array instead of just its first occurrence:

int count(int x) {
int cnt = 0;
for (int i = 0; i < N; i++)
cnt += (a[i] == x);
return cnt;
}


To vectorize it, we just need to convert the comparison mask to either one or zero per element and calculate the sum:

const reg ones = _mm256_set1_epi32(1);

int count(int needle) {
reg x = _mm256_set1_epi32(needle);
reg s = _mm256_setzero_si256();

for (int i = 0; i < N; i += 8) {
reg y = _mm256_load_si256( (reg*) &a[i] );
reg m = _mm256_cmpeq_epi32(x, y);
m = _mm256_and_si256(m, ones);
s = _mm256_add_epi32(s, m);
}

return hsum(s);
}


Both implementations yield ~15 GFLOPS: the compiler can vectorize the first one all by itself.

But a trick that the compiler can’t find is to notice that the mask of all ones is minus one when reinterpreted as an integer. So we can skip the and-the-lowest-bit part and use the mask itself, and then just negate the final result:

int count(int needle) {
reg x = _mm256_set1_epi32(needle);
reg s = _mm256_setzero_si256();

for (int i = 0; i < N; i += 8) {
reg y = _mm256_load_si256( (reg*) &a[i] );
reg m = _mm256_cmpeq_epi32(x, y);
s = _mm256_add_epi32(s, m);
}

return -hsum(s);
}


This doesn’t improve the performance in this particular architecture because the throughput is actually bottlenecked by updating s: there is a dependency on the previous iteration, so the loop can’t proceed faster than one iteration per CPU cycle. We can make use of instruction-level parallelism if we split the accumulator in two:

int count(int needle) {
reg x = _mm256_set1_epi32(needle);
reg s1 = _mm256_setzero_si256();
reg s2 = _mm256_setzero_si256();

for (int i = 0; i < N; i += 16) {
reg y1 = _mm256_load_si256( (reg*) &a[i] );
reg y2 = _mm256_load_si256( (reg*) &a[i + 8] );
reg m1 = _mm256_cmpeq_epi32(x, y1);
reg m2 = _mm256_cmpeq_epi32(x, y2);
s1 = _mm256_add_epi32(s1, m1);
s2 = _mm256_add_epi32(s2, m2);
}

s1 = _mm256_add_epi32(s1, s2);

return -hsum(s1);
}


It now gives ~22 GFLOPS of performance, which is as high as it can get.

When adapting this code for shorter data types, keep in mind that the accumulator may overflow. To work around this, add another accumulator of larger size and regularly stop the loop to add the values in the local accumulator to it and then reset the local accumulator. For example, for 8-bit integers, this means creating another inner loop that does $\lfloor \frac{256-1}{8} \rfloor = 15$ iterations.