15 ms·
The most important thing here is to measure. Always measure. It doesn't matter what you think is going to be fast or not. The combination of super smart (or not
by minimax 12y ago
The most important thing here is to measure. Always measure. It doesn't matter what you think is going to be fast or not. The combination of super smart (or not so smart) compilers, multi-level hierarchal caches, pipelining, branch (mis)prediction, etc means you can't just look at a piece of code in a high level language and know how fast it will be. You always have to run the code and measure how long it takes. For anything where you really care about latency, measure.
- TheLoneWolfling 12y ago...And then have something in an entirely unrelated set of code change and make the code you oh-so-carefully benchmarked become half as fast. Because you just caused cache line aliasing, or your pushed your function code across a boundary, or you're now killing your branch predictor, or, or... At this point, in any optimized language benchmarking parts of your code is practically useless for finer optimization. There are some things you will pick up on, sure, but trying to squeeze the last drop of performance out of your code? Good luck. Too many global interactions. I mean: even GCC doesn't generate statistically significantly faster code on O3 versus O2.