The more I interact with consteval and the whole template metaprogramming and codegen paradigm, the more I think it's completely inappropriate to shovel into stdlib. I don't think this should even be part of the language itself, but something more like a linter on top of the C++ language.
For most of us it seems you can get good at C++ or metaprogramming. But unless you want to make it your entire career you can't really do both with the same degree of effectiveness.
I really like C++, and I will probably continue using it forever. But really only the very small subset of the language that applies to my chosen field. I'm a "C with classes" kind of guy and templates and constexpr are pretty rare. Hell, half the time I don't even have stdlib on embedded platforms. It's kind of nice, actually.
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.
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.
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.
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.
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.
> 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.
I am actually glad that more and more of the metaprogramming techniques are built into the language itself, because people are going to try metaprogramming anyways, and their attempts at it are generally less readable without proper compiler support.
Anecdotally, I remember having to review a library written in C++98. It actually worked as promised, but it also did a lot of extremely clever things that were sort of unnecessary if we had just waited for C++11 with type_traits. We got rid of that library later after rewriting all the downstream dependencies.
For most of us it seems you can get good at C++ or metaprogramming. But unless you want to make it your entire career you can't really do both with the same degree of effectiveness.
I really like C++, and I will probably continue using it forever. But really only the very small subset of the language that applies to my chosen field. I'm a "C with classes" kind of guy and templates and constexpr are pretty rare. Hell, half the time I don't even have stdlib on embedded platforms. It's kind of nice, actually.