User: Password:
Subscribe / Log in / New account

The problem with prefetch

The problem with prefetch

Posted May 24, 2011 21:18 UTC (Tue) by oak (guest, #2786)
Parent article: The problem with prefetch

"As with other low-level optimizations (likely() comes to mind)"

-> Is there an article about downsides of likely() usage?

(Log in to post comments)


Posted May 24, 2011 21:55 UTC (Tue) by corbet (editor, #1) [Link]

A quick look in the LWN kernel index turns up an article from 2004, an article from 2006, and one from last December.


Posted May 25, 2011 13:10 UTC (Wed) by oak (guest, #2786) [Link]

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.


Posted May 30, 2011 15:21 UTC (Mon) by berkus (guest, #74327) [Link]

-fprofile-arcs first!


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.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds