Outsmarting the compiler: Short story about optimization
1–10 of 26 posts
Re: Outsmarting the compiler: Short story about optimization
#2Quick upvote for a well designed mobile friendly site. The last few HN posts I read were awful on mobile.
Re: Outsmarting the compiler: Short story about optimization
#3Outsmarting 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.)
Re: Outsmarting the compiler: Short story about optimization
#4Outsmarting 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.)
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.
Re: Outsmarting the compiler: Short story about optimization
#5Outsmarting 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.)
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 oth…
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.
Re: Outsmarting the compiler: Short story about optimization
#6This is not so much "outsmarting the compiler" as "working with the compiler" - tweaking code to trigger certain optimizations/generate particular output. The missing part, of course, is showing that these optimizations actually help...
Re: Outsmarting the compiler: Short story about optimization
#7Outsmarting 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.)
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 oth…
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.
Re: Outsmarting the compiler: Short story about optimization
#8Outsmarting 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.)
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 oth…
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.
Re: Outsmarting the compiler: Short story about optimization
#9When looking at code performance, it's important to remember that conditional branches are almost always cheap inside microbenchmarks, because the CPU can figure out when the same branches get taken on every loop... but far more expensive in the real world. A similar issue applies to cache: Your code might fit inside the L1 cache in your benchmarks, but when it's used in the real world you get cache misses since the rest of the program accesses data too.
Re: Outsmarting the compiler: Short story about optimization
#10How does this wrapper and each variant connect together? I supposed he would include a pointer to the actual struct in the wrapper, but I just see payload (that I'm gonna assume needs to be written to that array with padding in the actual struct).
For me, a wrapper includes the original thing and just wraps stuff around it. How does this work here? May also be a question to the author, I suppose now...