5

I have many validation checks in the code where program is crashed if any check gets failed. So all the checks are more unlikely.

if( (msg = newMsg()) == (void *)0 )//this is more unlikely
{
    panic()//crash
}

So I have used the macro unlikely which hints compiler in branch prediction. But I have seen no improvement with this(I have some performance tests). I am using gcc4.6.3.

Why is there no improvement ? Is it because there are no else case for this? Should I use any optimization flag while building my application?

edmz
  • 8,220
  • 2
  • 26
  • 45
spoorthi sreedhara
  • 51
  • 2
  • 2
    Hard to tell with this amount of data, but maybe simply because the hints you gave the compiler were already considered? – MatthewRock Dec 09 '15 at 11:57
  • 3
    The performance gains the likely/unlikely macros can be just a handful of processor cycles. Perhaps your performance tests are only accurate to a few micro seconds, or even milliseconds. Perhaps the compiler generated the optimal code anyway, even without your macros. – nos Dec 09 '15 at 11:58
  • 1
    If you want to improve the performance of your code, don't guess. You will be wrong. Profile it and **KNOW** what you need to work on. – Andrew Henle Dec 09 '15 at 12:09
  • See the 2nd comment, by Ross Rogers, in the answer http://stackoverflow.com/questions/109710/likely-unlikely-macros-in-the-linux-kernel-how-do-they-work-whats-their . It basically says that advance CPUs might have thier own branch predictor which could do the job of what unlikely does. – rahul.deshmukhpatil Dec 09 '15 at 12:14
  • By default, gcc already predicts p==0 as false (though not with as high a probability as if you use __builtin_expect). You can try `-fdump-tree-all-all` which shows some estimated probabilities. – Marc Glisse Dec 09 '15 at 14:00

2 Answers2

5

Should I use any optimization flag while building my application?

Absolutely! Even the optimizations turned at the lowest level, -O1 for GCC/clang/icc, are likely to outperform most of your optimization efforts. For free essentially, so why not?

I am using gcc4.6.3.

GCC 4.6 is old. You should consider working with modern tools, unless you're constrained otherwise.

But I have seen no improvement with this(I have some performance tests).

You haven't seen visible performance improvements, which is very common when dealing with micro-optimizations like those. Unfortunately, achieving visible improvements is not very easy with today's hardware: this is because we have got faster (unbelievably faster) components than they used to be. So saving up cycles is not as sensible as it used to be.

It's though worth noticing that sequential micro-optimizations can still make your code much faster, as in tight loops. Avoiding stalls, branch mispredictions, maximizing cache use do make a difference when handling chunks of data. And SO's most voted question shows clearly that.

It's even stated on the GCC manual:

— Built-in Function: long __builtin_expect (long exp, long c)
You may use __builtin_expect to provide the compiler with branch prediction information. In general, you should prefer to use actual profile feedback for this (-fprofile-arcs), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect.

(emphasis mine)

edmz
  • 8,220
  • 2
  • 26
  • 45
-3

See other answers related to this on SO:

likely(x) and __builtin_expect((x),1)

Why do we use __builtin_expect when a straightforward way is to use if-else

etc.

Search for it: https://stackoverflow.com/search?q=__builtin_expect

Community
  • 1
  • 1
wilx
  • 17,697
  • 6
  • 59
  • 114