3 ms·

We find constexpr (and associated templates) essential for when we need to avoid branch penalties. It makes the code so much simpler and cleaner than the altern

We find constexpr (and associated templates) essential for when we need to avoid branch penalties. It makes the code so much simpler and cleaner than the alternative. I'm glad the language caters to the needs of everyone, even if any individual person (self included) only uses a little bit of it.

PaulDavisThe1st 8mo ago
Yeah, I had an opportunity to use it for more or less precisely this case (avoiding a branch) a couple of years ago, and it was a delight to find. template<bool condition> void method () { .... if (condition) /* constexpr */ { extra_code; } .... } Which then allows method<true> and method<false> without a runtime branch.
- anematode 8mo ago
  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.

PaulDavisThe1st 8mo ago

Yeah, I had an opportunity to use it for more or less precisely this case (avoiding a branch) a couple of years ago, and it was a delight to find. template<bool condition> void method () { .... if (condition) /* constexpr */ { extra_code; } .... } Which then allows method<true> and method<false> without a runtime branch.

anematode 8mo ago
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.