3 ms·
Have you tried measuring the actual impact of this? This optimization is so old, I'm not even sure if it's still worth the effort. It definitely worked in the
by okaleniuk 3y ago
Have you tried measuring the actual impact of this?
This optimization is so old, I'm not even sure if it's still worth the effort. It definitely worked in the 90s.
What you do here is you save on division, and lose on instruction cache. This might look good on a benchmark when all your code fits the cache nicely, but bite back in-vivo. You should try it out in an actual problem and see how it goes.
- hoten 3y agoI know it's an appeal to authority, but if clang does it at high optimization levels then that's good enough for me to know it's faster. Division is really really slow in CPUs, as I understand it. Like, CPUs are just awful at it. It being an old opt doesn't mean it is invalid. I'm not aware of CPUs getting meaningfully better at division.
- okaleniuk 3y agoYou have to measure. It's a contextual optimization, no compiler in existence measures contextual optimization for you. Even the profile-based optimization is a spray and pray thing. CPUs are not getting better at division per se, but they are getting better at all the ALU operations compared to the memory latency. You can add more transistors on a chip, but you can't cheat the light speed and make signal travel 30 cm in less than a nanosecond. So you need to bring your data closer, you need caches. Code, unsurprisingly, is also data, and it also goes through the instruction cache. This optimization is instruction latency vs. cache intake. It may or may not be beneficial depending on the rest of the program. I've already seen both Clang and GCC produce faster code with -Os rather than with -O3.