This article is about algorithms, not compilers, and cares only about what the actual instructions are, so it’s better to treat it as if you have a compiler that will just do what you mean instead of trying to be clever (because in this instance that “compiler” is the reader). You still need to get your actual compiler to generate the right code, but that’s something to worry about later.
cmp [ecx], eax
adc edi, 0
(Figuring out how the above works is left as an exercise for the reader.)That is true, and the article mentions that GCC did not want to generate branchless code in this case, and thus performed much worse. Only Clang reliably generated the branchless code, and thus Clang was used for all of the benchmarking.
> the compiler was also free to turn the original 'if/then' structure into branchless code using conditional instructions
If we were just talking about:
if (*it < pivot) p++;
then I would agree with you. Optimizing this into the branchless version is a relatively trivial operation: p += (*it < pivot);
However the actual code was: if (*it < pivot) {
std::swap(*it, *p); // Could be a self-swap
p++;
}
This std::swap() line performs two memory reads and a memory write, but only if the condition is true. Eliminating the branch in this case will cause these memory operations to happen unconditionally, which means the optimizer will actually be introducing extra memory operations. This is the opposite of what you generally expect an optimizer to do: if anything you usually want an optimizer to reduce the number of memory operations being performed! The compiler would need to be extremely confident that this will somehow speed up the program overall, and it will also need to guarantee that none of these new loads/stores can possibly introduce memory errors (out-of-bounds reads or writes).For these reasons, I don't expect real compilers to ever translate the example above into the equivalent branchless code, as given in Andrei's article:
auto x = *read;
auto smaller = -int(x < pivot);
auto delta = smaller & (read - first);
first[delta] = *first;
read[-delta] = x;
first -= smaller;Because in branchless quicksort, no matter how long it takes to figure out where the element has to go relative to the pivot it doesn't obstruct the CPU's ability in this algorithm to start working on the next element the next cycle.
So a complement to the likely/unlikely annotations?
It probably depends on a core language accommodation because bitwise-swapping objects, or even primitive elements of objects, with constructors is UB.
Arthur O'Dwyer's P1144 https://wg21.link/p1144 explores that territory too.
Gcc has weird limits on generating CMOV instructions to implement this sort of optimization.
But running industrially important generic algorithms twice as fast as C++, automatically and without heroics, would be a Feather in Rust's Cap, and a Black Eye for C++. ("!!!!", as it were.) Or vice versa. Best would be if both got it, of course.
At present, both languages need heroics. I don't know of any other language where there is a reasonable prospect of getting such an optimization implemented generically, but that doesn't mean there aren't any.
Or, to put it another way, the compiler was also free to turn the original 'if/then' structure into branchless code using conditional instructions. My point is, surely neither version guarantees that the generated code is branchless, it's all still up to the compiler.