Thanks! So the issue with likely() was just people putting them to wrong places instead of un/likely() itself potentially slowing (things down that was half the issue with the explicit prefetch usage).
I typically use unlikely() in my code just to annotate ifs in error check&logging macros. If errors aren't unlikely, I think the performance of un/likely() is the least of my issues...
Posted May 25, 2011 15:30 UTC (Wed) by SLi (subscriber, #53131)
[Link]
I have also seen in user-space code that using the GCC equivalent of likely() in branches where I knew by profiling were much more likely to be either taken or not taken actually slows down the code. I don't quite understand the reason for this. Then in other cases it does indeed cause a speedup. When fine-tuning performance I have had to try it branch by branch to get the best results, and even then I'm not sure it generalizes to other processor models.
likely()
Posted May 30, 2011 15:21 UTC (Mon) by berkus (guest, #74327)
[Link]
-fprofile-arcs first!
likely()
Posted Jun 1, 2011 4:20 UTC (Wed) by AdamRichter (guest, #11129)
[Link]
Sometimes you want to minimize latency for the less commonly used but more important branch, such as in almost any polling loop.