4 ms·

The cardinal question: is the benefit of removing that branch worth the increase in i-cache footprint? I think it depends quite a bit... but also, the speed inc

The cardinal question: is the benefit of removing that branch worth the increase in i-cache footprint? I think it depends quite a bit... but also, the speed increases IME from doing this kind of thing can result not merely from the branch removal, but from the code duplication itself. Even if the contents of the branch doesn't directly mention the condition, duplication allows the surrounding code to be separated in the branch predictor, and it's quite common that these conditions will correlate with different branch frequencies in the surrounding. code.

jeffbee 8mo ago
I work on a codebase where I am slowly detangling all of the tens of thousands of lines of `if constexpr` templates that were written by a guy who doesn't know how a modern CPU works. It's a bad meme with a very narrow field of beneficial applications. People who think a mispredicted branch is costly are never gonna believe the cost of a page table walk caused by an iTLB miss.
- anematode 8mo ago
  Narrow indeed. If the function is small enough for the i-cache pressure to not matter, it's probably going to get inlined and the condition gets optimized out anyway. If it's big enough, then it's unclear, but microbenchmarks will give you misleading results.
dataflow 8mo ago
> is the benefit of removing that branch worth the increase in i-cache footprint? Like everything else in the world, in general, it depends. That said, among the limited number of times I've tried this, I don't recall a single case where I felt it would be worth it and it turned out to be detrimental.
PaulDavisThe1st 8mo ago
Yep, that was my thinking as well. Two things: 1. this is being used in a method that is widely used in both the <true> and <false> contexts, which I believe means that branch prediction would not be great if it was simply the same instruction sequence in both contexts. I could be wrong about that. 2. the major benefit that I saw was not duplicating the much more substantial code in the "..." sections (before and after the constexpr) and thus making maintainance and continued evolution of the code more reliable.

jeffbee 8mo ago

I work on a codebase where I am slowly detangling all of the tens of thousands of lines of `if constexpr` templates that were written by a guy who doesn't know how a modern CPU works. It's a bad meme with a very narrow field of beneficial applications. People who think a mispredicted branch is costly are never gonna believe the cost of a page table walk caused by an iTLB miss.

anematode 8mo ago
Narrow indeed. If the function is small enough for the i-cache pressure to not matter, it's probably going to get inlined and the condition gets optimized out anyway. If it's big enough, then it's unclear, but microbenchmarks will give you misleading results.

dataflow 8mo ago

> is the benefit of removing that branch worth the increase in i-cache footprint? Like everything else in the world, in general, it depends. That said, among the limited number of times I've tried this, I don't recall a single case where I felt it would be worth it and it turned out to be detrimental.

PaulDavisThe1st 8mo ago

Yep, that was my thinking as well. Two things: 1. this is being used in a method that is widely used in both the <true> and <false> contexts, which I believe means that branch prediction would not be great if it was simply the same instruction sequence in both contexts. I could be wrong about that. 2. the major benefit that I saw was not duplicating the much more substantial code in the "..." sections (before and after the constexpr) and thus making maintainance and continued evolution of the code more reliable.