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)

likely()

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.

likely()

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...

likely()

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.


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