5 ms·
The link is helpful for background, but is it really useful to tell a programmer who is worried about i-cache contention to be guided by an automatic profiler r
by nkurz 12y ago
The link is helpful for background, but is it really useful to tell a programmer who is worried about i-cache contention to be guided by an automatic profiler rather than forcing the compiler to do what they want and then profiling that? I'm intrigued --- what prompts you to give this advice? It's the opposite of my instinct. Have you personally experienced issues with this?
- tacos 12y agoProgrammers are horrible at guessing branch prediction. It's a famous truism. And the only thing worse than guessing the branch prediction wrong would be moving the code farther away then adding a jump to it and back. The next level of mistake is gathering the profile data from the unit tests. (Hey! Free Input!) Ugh. Hardcoding "Case 5: is most often" in a library also bit me. If you're giving me the source, let me guide the paths, thanks. Maybe you use Case 5, maybe my code doesn't. (And I just stepped through Clang doing the exact right thing on a switch statement with inlining.)
- enqk 12y agoI think you should have stated upfront that you were asking library-writers not to do that, because it's hard to guess actual branching profiles there. I don't think your advice apply that much to an application writer.
- userbinator 12y agoProgrammers are horrible at guessing branch prediction. Not for error cases like the ones described in the article.
- gumby 12y agoThe article doesn't give any specific situations for doing this (apart from the example of an uncommon error case). You could indeed be doing this specifically from the result of looking at the profiler and then reading the assembly code output of a hotspot.
- mattgodbolt 12y agoThat's a weakness of the article...sorry. I use it to handle error cases in otherwise very performant straight-line code.