3 ms·
As long as std::sort can fit in the instruction cache, who cares? (outside the embedded world obviously) It will always be faster unless you're getting regular
by btmorex 12y ago
As long as std::sort can fit in the instruction cache, who cares? (outside the embedded world obviously) It will always be faster unless you're getting regular instruction cache misses.
- makomk 12y agoEven if each instance of std::sort fits in the instruction cache, it's helping to push some other code elsewhere in the program out of the instruction cache, slowing that code down in the process.
- humanrebar 12y agoIf std::sort pushes something out of icache, it's to make room for inlining swaps and compares. I'm skeptical that the other things bumped from icache should be kept hotter.
- rasz_pl 12y agoYes, and if it doesnt just wait for better CPU, right? You work for microsoft?
- humanrebar 12y agoIf it doesn't, use qsort. C++ lets you do that.
- ant6n 12y agoUnless you sort 10 elements
- comex 12y agoIn addition to the "unless you sort 10 elements" factor, as stated in a sibling comment - LLVM + libclang together are already 46MB of code, and they're libraries designed to be statically linked. Sure, they aren't going to fill your drive, but they will take a comparative while to load from disk (especially as part of another application - doesn't matter much on the command line), and it's that much harder to justify including them in an otherwise small downloaded package.