3

I read about the attributes likely and unlikely of c++20, and i want to ask if there are some reasonable and official data of performance advantages that this new attributes give to the execution.

I mean there are examples execution test that give me a measure of how much this feature has impact on performance when the code is executed?

I noticed that this attributes are often used in linux kernel development ( in C code ). So my question is:

Does not the compiler optimaze the code sufficiently already? There are example or proof of the effective improved performances?

Is this true for all kind of machine or some architectures need Likely/Unlikely for a good improvement?

EDIT :

I'm searching for Graph or data that demostrate the effeciency of this kind of suggestion to the compiler. ( I search online, but i don't find nothing good ) If someone know some paper, or similar can answer this question?

Zig Razor
  • 3,381
  • 2
  • 15
  • 35
  • 1
    In most cases you don't need them. The compiler will do a better job if you don't interfere. In *rare* cases they can be a win (mostly in OS kernel code and other similar low-level situations). In *general*; forget they exist, you are likely to do more harm than good by using them. – Jesper Juhl Jan 11 '20 at 15:00
  • ok, but there are some example of bad use and good use? – Zig Razor Jan 11 '20 at 15:04
  • 3
    An obvious *bad* use would be to mark an "always taken" branch as *unlikely*. – Jesper Juhl Jan 11 '20 at 15:06
  • ok, i don't mean this easy example,.. you say the compiler can do better solo, which is the bad and good example for this? – Zig Razor Jan 11 '20 at 15:10
  • Do you think you can do a better analysis of whether branches are likely/unlikely than the compiler? Sure, for a toy program, maybe, but for a real project? I doubt it. – Jesper Juhl Jan 11 '20 at 15:13
  • 3
    This is a portable version of the GNU C feature, right? See [How do the likely/unlikely macros in the Linux kernel work and what is their benefit?](//stackoverflow.com/posts/comments/70654751) and Ciro Santilli's answer on the same question. (The accepted answer there is unfortunately wrong and should be downvoted; it's not runtime branch *prediction* that benefits). Also semi-related: [gcc optimization flag -O3 makes code slower than -O2](//stackoverflow.com/q/28875325) has some details re: GCC deciding whether a branch is likely to be predictable or not, and if-conversion to CMOV – Peter Cordes Jan 11 '20 at 15:26
  • 1
    [Can likely/unlikely macros be used in user-space code?](//stackoverflow.com/a/1668114) also points out that "What Every Programmer Should Know About Memory" has a section about how improved branch layout giving better locality in L1 I-cache. – Peter Cordes Jan 11 '20 at 15:30
  • 3
    If you want measurements, I suggest you take a look at the proposed paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0479r0.html – JVApen Jan 11 '20 at 18:04
  • @JVApen thank you this is the kind of papers that i search for – Zig Razor Jan 11 '20 at 18:09
  • there are some other that can help me with other papers or with a good explanation? – Zig Razor Jan 15 '20 at 10:30
  • 3
    @JesperJuhl "An obvious bad use would be to mark an "always taken" branch as unlikely." That's actually not entirely true, if you have some busy polling code you want to mark the always taken branch (e.g.: no data on read) as unlikely to make the compiler optimize the unlikely but important branch. – Stephan Dollberg Jan 25 '20 at 21:40
  • @inf good point. – Jesper Juhl Jan 26 '20 at 12:34
  • *need* no, that's far too strong a word. In general compilers usually do a pretty good job most of the time. I think the existing Q&As about likely/unlikely macros already pretty much cover it; minor code layout benefits. It can be hard to microbenchmark, especially when the benefit is touching fewer lines of L1i cache. – Peter Cordes Feb 07 '20 at 16:17
  • re: edit: requests for links to docs, guides, benchmarks, or other off-site resources are off-topic for Stack Overflow, sorry. Benefits depend on details of the use-case, and what the compiler was doing *without* the hint. So it depends on which compiler with what options, and on what hardware you test on. Hard to systematically test anything because it depends on the details of a particular case, and knowing which conditions to annotate. I guess you could maybe find some code already using GNU C `__builtin_expect` likely / unlikely macros and see what happens when you remove them. – Peter Cordes Oct 07 '20 at 23:56

0 Answers0