3 ms·
Even the best coders often get this wrong. Let the profiler do it. http://llvm.org/docs/BranchWeightMetadata.html http://llvm.org/docs/BranchWeightMetadata.htm
by tacos 12y ago
Even the best coders often get this wrong. Let the profiler do it.
http://llvm.org/docs/BranchWeightMetadata.html http://llvm.org/docs/BranchWeightMetadata.html
- nkurz 12y agoThe 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.
- ot 12y agoSee my other comment (https://news.ycombinator.com/item?id=8906866 https://news.ycombinator.com/item?id=8906866) The compiler can optimize the layout of the basic blocks according to its beliefs (or hints) on the branch probabilities, but it won't move a code path to a separate function. I don't know if this could be done in compliance with the standard, but I haven't seen any compiler do it. EDIT: I stand corrected, looks like GCC 4.9 can do it (http://goo.gl/amM4Et http://goo.gl/amM4Et). Still, it didn't do it when I needed it :)
- DannyBee 12y agoFunction outlining can be done, if it's not being done, you don't have the right options or it's deciding it's not profitable. (and FWIW, ICC has done this for at least 8 years)
- repsilat 12y agoWhy put it into a separate function? You could just movie it to the end and jump there and back，saving the call overhead.
- Rusky 12y agoIt makes the function smaller, making it easier to inline. This might matter depending on how easy it is for the compiler to do partial inlining.
- DannyBee 12y agoCall overhead would be nil, since it created the function, and thus it does not have to follow normal argument passing behavior :) In effect, it will just be a bunch of gotos.