Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Attribute: Likely, Unlikely

en.cppreference.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: C++ Attribute: Likely, Unlikely

#61

Post by plorkyeran »

pjmlp wrote: post #10
corysama wrote: post #6

Earlier quoted context omitted.

These annotations are really only of interest in performance-critical computations. It’s another knob for library writers to use to make the libraries you use magically faster for their users. And, should be quite rare outside of libraries.

And even then they should be handled with extreme care, as they can trigger UB if used incorrectly.

Some attributes can cause UB (most obviously [[unreachable]] in a spot that's reachable), but [[likely]] and [[unlikely]] can't.

Re: C++ Attribute: Likely, Unlikely

#62

Post by plorkyeran »

nickysielicki wrote: post #13

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…

My experience with PGO it that it's a much larger footgun. If you can't profile your actual production workload then it's very frequently just going to make your program slower. Even if you can profile production, it's still an easy way to completely blow out your long-tail latency for codepaths that PGO decides don't matter.

Re: C++ Attribute: Likely, Unlikely

#63

Post by gumby »

gpderetta wrote: post #38
gumby wrote: post #33

I often write my code pessimally in this regard so have a note in the back of my mind to someday use these in a few hot paths. When I say “pessimally” I mean I usually check the unlikely cases right away and then put the normal case last: Blah foo (something& arg) { if (is_invalid (arg)) return blah(0); if (is_inactive (arg)) return blah(1); // ok do all the normal stuff } It makes the code clearer but slightly slowe…

> I usually check the unlikely cases right away and then put the normal case last. Don't we all?

If only I lived in such a paradise!

Re: C++ Attribute: Likely, Unlikely

#64

Post by JonChesterfield »

ReleaseCandidat wrote: post #22

What everybody should read before using these (Aaron Ballman is a Senior Staff Compiler Engineer for Intel and is the lead maintainer of the Clang open source compiler): https://blog.aaronballman.com/2020/08/dont-use-the-likely-or...

This is a pretty coherent argument that that new feature is broken and best ignored. Hopefully that's the approach clang will take.

PGO is a mixed blessing and detracts a bit from the thrust of the article. The more obvious conclusion is to continue using builtin_expect (on the boolean guard of a branch) which works great and has done for ages.

Re: C++ Attribute: Likely, Unlikely

#66

Post by WiSaGaN »

I think this is likely (no pun intended) be confusing in case that we want to optimize for the case that is unlikely to occur. In HFT, you basically want to be fast in a few cases, and don't care that much about the cases where you would not act (which is majority of the case comparing to the number of markets event where you need to make decision on).

Re: C++ Attribute: Likely, Unlikely

#67

Post by pjmlp »

JonChesterfield wrote: post #64
ReleaseCandidat wrote: post #22

What everybody should read before using these (Aaron Ballman is a Senior Staff Compiler Engineer for Intel and is the lead maintainer of the Clang open source compiler): https://blog.aaronballman.com/2020/08/dont-use-the-likely-or...

This is a pretty coherent argument that that new feature is broken and best ignored. Hopefully that's the approach clang will take. PGO is a mixed blessing and detracts a bit from the thrust of the article. The more obvious conclusion is to continue using builtin_expect (on the boolean guard of a branch) which works great and has done for ages.

That is also covered by new C++ attributes, namely [[assume(expr)]].

However better not give data to the function that contradicts the condition if you don't want to figth nasal daemons.

Re: C++ Attribute: Likely, Unlikely

#68

Post by [deleted] »

twoodfin wrote: post #55
bee_rider wrote: post #47

Earlier quoted context omitted.

> I could always write a conditional for the hot path up front, but code is for human readers, right? Does C or C++ actually make any promises that it’ll assume the “true” branch of the conditional will be taken? I always assumed that the compiler could make whatever weird decision it wants for that sort of thing. TBH I’d probably just write normal stuff as a function, and then call that function directly in cases wh…

No. The traditional compiler heuristic is to assume backwards branches are taken (loops) and forward branches are not.

[deleted]

Re: C++ Attribute: Likely, Unlikely

#69

Post by JonChesterfield »

pjmlp wrote: post #67
JonChesterfield wrote: post #64

Earlier quoted context omitted.

This is a pretty coherent argument that that new feature is broken and best ignored. Hopefully that's the approach clang will take. PGO is a mixed blessing and detracts a bit from the thrust of the article. The more obvious conclusion is to continue using builtin_expect (on the boolean guard of a branch) which works great and has done for ages.

That is also covered by new C++ attributes, namely [[assume(expr)]]. However better not give data to the function that contradicts the condition if you don't want to figth nasal daemons.

Glad assume(expr) is available, if it maps onto builtin-expect but confused by the UB reference. Why would taking the less likely path be undefined behaviour?

Edit. It's because assume does not map to expect, it maps to builtin_assume. So that's just another way to write undefined c++.

Re: C++ Attribute: Likely, Unlikely

#70

Post by pjmlp »

JonChesterfield wrote: post #69
pjmlp wrote: post #67

Earlier quoted context omitted.

That is also covered by new C++ attributes, namely [[assume(expr)]]. However better not give data to the function that contradicts the condition if you don't want to figth nasal daemons.

Glad assume(expr) is available, if it maps onto builtin-expect but confused by the UB reference. Why would taking the less likely path be undefined behaviour? Edit. It's because assume does not map to expect, it maps to builtin_assume. So that's just another way to write undefined c++.

Ah, I thought it was the same, I spend most of my C++ coding time on VC++ anyway.
Post reply on HN