5 ms·
This sounds very similar to the criteria used by the Go team as to whether to add compiler optimizations or not, namely the optimization should speed up the com
by nickcw 9y ago
This sounds very similar to the criteria used by the Go team as to whether to add compiler optimizations or not, namely the optimization should speed up the compiler by at least an amount that the extra computation of the optimization takes.
I don't think the go team worry about the size of the object as much though.
- david-gpu 9y agoImagine using that yardstick to guide what optimizations to implement on a FORTRAN compiler -- it would be absurd! Most workloads don't have a lot in common with a compiler.
- tzar 9y agoImagine advertising FORTRAN as a developer-friendly language with fast compilation times! I'm sure the Go folks are using this metric because it's compatible with their goals, which aren't everyone's.
- weberc2 9y agoThe Go team has a whole bunch of benchmarks besides compiler performance by which they judge the language. Certainly maintaining good compiler performance means giving up some low-value optimizations, but it doesn't mean compiler performance is their only benchmark.
- kwhitefoot 9y agoLast time I used a Fortran compiler my impression was that it was faster than compilers for most other common languages. And if you are developing scientific software I suspect that it is as developer friendly as most currently common languages.
- bjourne 9y agoI doubt that because it is only possible for the most trivial of compiler optimizations. For example, most compilers perform loop hoisting which speeds up unhoisted code. But if you are writing performance sensitive code to be used in a compiler, you would have hoisted your variables manually anyway! Other examples include register allocation which you can either do slow using graph coloring or fast using linear scan. Graph coloring leads to better code, but much slower compilation times. The compiler optimization that "pays for itself" is like a holy graal, it doesn't exist. :) No such thing as a free lunch. In the article they admit that, but argues that the somewhat slower compile times is worth it.