1 comment

[ 3.7 ms ] story [ 11.0 ms ] thread
This looks pretty interesting, and it's also cool to see situations where the hardware manual says you should not do something, while in practice it is okay due to the way the hardware is actually implemented (basically, relying on undocumented guarantees).

It would be nice to see some performance numbers for this as well, since CPUs obviously also have branch predictors and might be able to make branches really cheap if they always take a certain branch, especially in a hot loop, where this kind of optimization is most likely to happen.

I could also imagine that the use of inline assembly for control flow makes the compiler able to do less optimizations due to having less understanding of the control flow (the effect of that is harder to test in a microbenchmark). Maybe it's okay though if it's not volatile inline assembly.

Another way to achieve something similar to this is to use C++ templates to generate multiple versions of your code where you hardcode the branches so they get removed at compile time. Of course, for N branches this requires 2^N versions of your code, so it doesn't scale well to large number of branches, but it might allow you to push a few branches out of your hot loop into a higher level where it gets tested less often.