2 ms·
It's definitely not showing the effect of memory fetch prediction, as the entire benchmark should fit in L1 cache. The point of the benchmark was to show how m
by dalke 3y ago
It's definitely not showing the effect of memory fetch prediction, as the entire benchmark should fit in L1 cache.
The point of the benchmark was to show how much overhead there is for using the method. It doesn't do any memory traversal at all - it's the iterator equivalent of:
long long benchmark_for_loop(int w, int h, int bad_i, int bad_j) {
long long count = 0;
for (int i=0; i<w; i++) {
for (int j=0; j<h; j++) {
if (i == bad_i || j == bad_j) {
return INVALID;
}
count++;
}
}
return count;
}
What the zigzag benchmark shows is the overhead for the few additional operations needed to figure out if it's traversing left or right; more specifically the "if (row % 2 == 0)" test and the else clause of the following:
*i = row = local.pos / local.h;
col = local.pos % local.h;
if (row % 2 == 0) {
*j = col;
} else {
*j = local.h - col - 1;
}
The factor of 4 performance difference between the for-loop and the row iterator is all due to function call overhead for the iterator API.