Hacker News new | ask | show | jobs
by taneq 3274 days ago
Outsmarting the compiler: A short story about optimisation:

"Don't."

The end.

(Basically, as the story shows, with this kind of micro-optimization you may or may not beat the compiler but you're almost certainly wasting your time compared with more effective optimization methods, like rethinking the problem.)

2 comments

This is stupid because it categorically denies the business case for micro-optomization.

Yet, a business case might exist when the library is heavily utilized, or often when a compiler isn't able to produce the correct code.

There are also cases primarily, in finance, where single threaded low-latency distinguishes competing groups. Some of those guys count every nanosecond.

The techniques described here ( and in other places) are universally applicable.

I recently played around with some code I wrote in college [1] which involves a pair of intertwined functions. I decided to play around with the SSE extensions on modern CPUs and write a vectorized version of the code.

Try as I might, I could not beat GCC [2], which used non-vectorized code. I chalk it up to not knowing how best to write optimized x86 code anymore (it's been years since I did any real assembly language programming) and I might be hitting some scheduling or pipeline issues, I just don't know.

[1] I described the code years ago here: http://boston.conman.org/2004/06/09.2

[2] I beat clang easily though.

The business case only makes sense when backed up by a profiler and an actual real business case regarding unhappy customers.

When that isn't the case, it is just wasting money.

In my experience, microoptimization tends to be more a matter of how to organize your code so as to enable the compiler to do the optimizations for you. Cases where the compiler is outright too stupid to find the optimization you want even with repeated prompting tend to be rare nowadays, and probably justify a bug report.
It does not. I said (emphasis added):

> you're almost certainly wasting your time compared with more effective optimization methods

Some rare cases absolutely do exist where specific micro-optimizations such as these may be useful - I'm not arguing that they don't.

Even in those cases, though, you're far more likely to achieve significant performance gains by taking a step back and re-examining your high level goals and your approach to the problem.

I'm not saying that eliminating a branch or two is never going to be useful. I'm just saying you should focus your attention elsewhere first.

In this case, yes, optimizations don't appear to be giving me much of a win. Although, I'm very glad I checked! There are certainly some very realistic scenarios in which it would be valuable to save this branch.