We often hear that choosing the right algorithm will get rid of all performance problems. There is no "need" to understand what is happening under the hood and all programmers should only work at higher levels of abstraction.
My take away from this question and and the top answer was that the above is not true. It does not mean that everyone has to code using assembly - it means that good programmers are aware of where their abstractions may leak.
Knowing the character of your data is priceless. The only time I was able to throughly beat GCC with optimizations is when I knew that most 32-bit values being calculated upon are actually fairly small (in tens of thousands) and that I could use that to my advantage.
Summary: due to deep pipelines and branch prediction, a tight loop with a single if statement goes fastest if the test nearly always comes out the same way as last time, and slowest when it is true or false at random.
It is a perfect example of why you need to know the low level gritty details of how modern CPU’s (and Caches/RAM) works to write high performance high level code. A few years ago I optimised a C++ constraint algorithm from 47 minutes to 2 secs by re-arranging how the data access was organised. Writing your code in C++ doesn’t automatically make it fast. You still need to understand the low level details to make fast code.
13 comments
[ 0.21 ms ] story [ 43.6 ms ] threadMy take away from this question and and the top answer was that the above is not true. It does not mean that everyone has to code using assembly - it means that good programmers are aware of where their abstractions may leak.
Related reading (can't believe it's almost 20 years since this article was written) - https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
https://stackoverflow.com/questions/1732348/regex-match-open...
Sadly the page is currently locked, likely as a conspiracy to avoid it overtaking the OP.