Live data from Hacker News

C++ Attribute: Likely, Unlikely

en.cppreference.com

21–30 of 70 posts

Re: C++ Attribute: Likely, Unlikely

#21
post #3

This seems like it will clutter code. I wish it was more terse as I find modern C++ code bases to be way too verbose already. It starts to get straining when looking at new modules.

This is standardizing vendor-specific attributes that have existed for many years. The code that use these probably use some preprocessor macro to select the right builtins, and aren't going to gain much new clutter to replace those macros. I believe this is the proposal that added them: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p04... The "references" section has links to GCC and Clang builtins: https…

Doesn't look like it. The attribute goes on branches. This goes in the middle of basic blocks. Doesn't seem better to me, might try to find the rationale for the invention instead of standardising existing practice. That proposal shows the existing attributes with different syntax.

Re: C++ Attribute: Likely, Unlikely

#23
post #17

A common use case for these is to prevent the compiler from inlining the unlikely case to avoid thrashing the instruction cache. if (unlikely_condition) { // Don’t inline this expensive_operation(); } It’s a good idea to check the generated assembly when using these as they can lead to weird reordering of the code.

It may also help a bit with a cold branch predictor and with icache hit rate

The compiler can make sure that the body for the likely condition is inline with the rest of the code, while the unlikely condition (e.g. the else block of a likely if) can be outlined behind a forward branch

Keeping the unlikely code further aside and behind a branch helps the happy path stay hot and well-predicted

Re: C++ Attribute: Likely, Unlikely

#24
post #7
post #3

This seems like it will clutter code. I wish it was more terse as I find modern C++ code bases to be way too verbose already. It starts to get straining when looking at new modules.

I suppose there is no reason you can’t profile your code and have a tool insert these hints based on actual statistics from execution.

In my experience PGO is absolute garbage (for languages like C and C++). For complex programs all it does is bloat the code with no measurable benefit. And for every set of inputs where it improves performance there is another where it introduces slowdowns.

Re: C++ Attribute: Likely, Unlikely

#27
post #11

In GCC you can already use (both on functions¹ and labels²) __attribute__(hot) and __attribute(cold) 1. https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Functio... >; Since GCC 4.3, released March 5, 2008 2. https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Label-Attribut... >; Since GCC 4.8, released March 3, 2013

The typical expansion of pre attribute likely/unlikely macros (for example from the linux kernel) is buitin_expected. Hot/cold should also work if a bit extreme.

Re: C++ Attribute: Likely, Unlikely

#28

Any ideas how "likely" it needs to be benefit from likely? more than 50%? or 75%? or 90%? Can it be detrimental if it has higher changes but still close to 50%?

Yes, you could imagine a bunch of scenarios where this could hurt you. Imagine a compiler that outlines the rare branch in order to shrink the code size of the function so that the hot path has better icache performance. That function call you inserted is expensive.

Re: C++ Attribute: Likely, Unlikely

#29

See also: https://blog.aaronballman.com/2020/08/dont-use-the-likely-or... tl;dr: these attributes are absolutely full of footguns because the standard is not explicit about precedence and nesting, and you should probably avoid them and prefer to spend time investing in PGO. It’s very easy to make sane-looking code containing these attributes which does the exact opposite of what you intended. Note that this issue doe…

Oh, I didn't see this before posting. Well, at least the chance is higher that somebody reads the article ;)

Re: C++ Attribute: Likely, Unlikely

#30

See also: https://blog.aaronballman.com/2020/08/dont-use-the-likely-or... tl;dr: these attributes are absolutely full of footguns because the standard is not explicit about precedence and nesting, and you should probably avoid them and prefer to spend time investing in PGO. It’s very easy to make sane-looking code containing these attributes which does the exact opposite of what you intended. Note that this issue doe…

PGO is not a silver bullet. If you've identified a problem that can be solved by a simple static hint you should do that. I agree littering your code with likely/unlikely will probably make things worse, so it's best to save them for those exceptional cases where you know it will make an improvement.
Post reply on HN