[denton-scratch]

So, by making your code harder to read ("Duh - both these branches do the same thing, so I'll refactor it"), you can give the optimiser actionable information.

But it's not explicit in the code; you'd need a comment in the code to explain your reasons. Comments rot. And your tuned "high-level" code (yeah, C++ isn't generally considered a high-level language) is now dependent on some specific optimizer, which might change in the future; code that appears to be portable, and compiles on multiple compilers, only performs properly if you use the right optimizer.

I don't like this advice; but I'm not a C++ programmer. I don't like macros, and I'm not at all keen on the merciless optimizers that are shipped with modern compilers.

[bunderbunder]

I'm generally opposed to unnecessary optimization, but I'm also opposed to this tendency to start flaming as soon as people even talk about optimization.

Because sometimes this kind of careful performance tuning, even at the cost of readability, is necessary and desirable. And, for the times when that happens, this kind of information needs to be out there, available, and being discussed, so that people can learn the techniques and understand how to use them properly and responsibly.

Yes, that does include knowing that a change to the compiler's optimizer could mean that things that used to make the code faster now make it slower. For that matter, changing the CPU microarchitecture could have the same effect. But that's something we all learn in Optimizing 101. It's so well-known that the very first setting on Godbolt's output pane is a toggle to select which compiler and version it should use to generate said output.

[denton-scratch]

> this kind of information needs to be out there

Agreed; I think TFA is a useful article. Highly-tuned code is going to be hard to read (it used to be written in assembler, which is at least explicit).

I was simply commenting on the opacity of having two branches in the source that appear to do the same thing, and rely on something outside the code (or the language specification) to achieve the desired performance.

[bunderbunder]

The language specification covers the semantics and correctness of the code. Excepting some very specific things such as tail call elimination that also touch on semantics, optimizations do not belong in the language specification.

If we did have a principle saying that you can't get clever with optimization or take advantage of your language's optimizer, that would imply that the past 15-20 years of growth of Web technology was based on an invalid foundation: the v8 JavaScript engine and people's efforts to learn how to use it effectively and push what's possible in a browser.

You'd also have much less impressive video games, and your smartphone would have worse battery life.