5 ms·
Can't answer your question, but here's the law (I was curious myself): > I claim the following simple experiment supports this depressing claim. Run your favo
by float4 4y ago
Can't answer your question, but here's the law (I was curious myself):
> I claim the following simple experiment supports this depressing claim. Run your favorite set of benchmarks with your favorite state-of-the-art optimizing compiler. Run the benchmarks both with and without optimizations enabled. The ratio of of those numbers represents the entirety of the contribution of compiler optimizations to speeding up those benchmarks. Let's assume that this ratio is about 4X for typical real-world applications, and let's further assume that compiler optimization work has been going on for about 36 years. These assumptions lead to the conclusion that compiler optimization advances double computing power every 18 years. QED.
> This means that while hardware computing horsepower increases at roughly 60%/year, compiler optimizations contribute only 4%. Basically, compiler optimization work makes only marginal contributions.
> Perhaps this means Programming Language Research should be concentrating on something other than optimizations. Perhaps programmer productivity is a more fruitful arena.
https://proebsting.cs.arizona.edu/law.html https://proebsting.cs.arizona.edu/law.html
- Waterluvian 4y agoI find that code performance optimization is not worthwhile a lot of the time. But developer performance optimization is almost always worthwhile. One might argue that cheap overseas development labour makes it a commodity, but I care more for being humane towards humans than CPUs.
- yakubin 4y agoA lot of times code compiled with no optimisations (-O0) is unusable. Specifically, in video some software compiled without optimisations won't push frames on time and instead will just keep dropping frames. There was a post a couple days ago about it being problematic in the games industry where a game compiled without optimisations is unplayable, while higher optimisation levels are hard to inspect in a debugger, due to the myth of "zero-cost-abstractions" in C++. Also to put it on its head a bit, when a compiler isn't fast enough (read not enough work was put into performance of the compiler itself, mostly on the design level, not on the microoptimisation level really), the feedback loop is so long, that developers stop testing out hypotheses and instead try to do as much as possible in their heads, without verifying, only to avoid the cost of recompiling a project. Another instance: when a photo-editing application can't quickly give me a preview of the photo I'm editing, I'm going to test fewer possible edits and probably get a worse photo as a result. With websites, if an action doesn't happen within a couple seconds of me clicking I often assume the website doesn't work and just close it, even though I know there are a lot of crappy websites out there that are just this slow. Doesn't matter. The waiting usually isn't worth my time and frustration.
- oriolid 4y ago> One might argue that cheap overseas development labour makes it a commodity It was already argued in 90s, and several companies bet on outsourcing to India. It wasn't a success for everyone.
- necubi 4y agoCompiler optimizations can actually improve developer productivity, because they allow developers to write clean but inefficient code that can be rewritten to near optimal form. For example, in Rust iterators are a very convenient and clear interface that are generally zero cost (sometimes even more efficient) compared to a manual loop implementation. But without optimization, they would be many times slower.
- bombcar 4y agoSome of that computer horsepower increase is due to chips learning how compilers create code and optimizing for compiled code.