4 ms·

Part of the reason compilers don't do really thorough analysis and optimization is that it makes the compiles take a long time. But we can make that not matter

by ef4 13y ago

Part of the reason compilers don't do really thorough analysis and optimization is that it makes the compiles take a long time. But we can make that not matter if we rethink the relationship between the compiler and the programmer. What if you got the first version of your binary very quickly, but then you could let the compiler run arbitrarily long, and watch it continue to produce better and better versions? What if the compiler could compile not just source code, but diffs of source code? It could apply your one-line change without redoing its exhaustive analysis of all the things that you couldn't have effected. Compilers try hard to avoid whole-program analysis, but I think that's misguided. Spend the cycles, they're getting cheaper all the time. If you can update your analysis incrementally as the programmer works, you're golden.

Dewie 13y ago
> Part of the reason compilers don't do really thorough analysis and optimization is that it makes the compiles take a long time. Compiler flags are all you need to solve that, no?
- wtallis 13y ago
  Only in the strictest sense. The mere presence of the switches does nothing on its own to improve the workflow. You need a development environment that is aware of why you're running the compiler: basic syntax checking, deeper static analysis using expensive heuristics, unoptimized code generation for quick turnaround time on correctness tests, or optimized code generation for performance testing.
kazagistar 13y ago
The diff thing sounds good, but there are many layers of optimizations in between the top and the bottom, and so a small change can cascade into a tremendous number of changes. Also, holding the entire tree of intermediate data, at each step, uses a lot of memory. That said, check out Julia: for any function, you can see how it looks at each step of compilation, down to assembly: source, optimized source, type inferred source (for given input types; it is a dynamic language), LLVM bytecode, and assembly. All visible and introspectable at runtime from either the REPL or scripts.
eru 13y ago
I am currently working with an in-house language that does only whole program analysis. If you have to be restricted to one or the other, you want separate compilation---the compiler times are just so horrible otherwise. (Optional whole program analysis compilation is fine, though.)

by ef4 13y ago

Dewie 13y ago

> Part of the reason compilers don't do really thorough analysis and optimization is that it makes the compiles take a long time. Compiler flags are all you need to solve that, no?

wtallis 13y ago
Only in the strictest sense. The mere presence of the switches does nothing on its own to improve the workflow. You need a development environment that is aware of why you're running the compiler: basic syntax checking, deeper static analysis using expensive heuristics, unoptimized code generation for quick turnaround time on correctness tests, or optimized code generation for performance testing.

kazagistar 13y ago

The diff thing sounds good, but there are many layers of optimizations in between the top and the bottom, and so a small change can cascade into a tremendous number of changes. Also, holding the entire tree of intermediate data, at each step, uses a lot of memory. That said, check out Julia: for any function, you can see how it looks at each step of compilation, down to assembly: source, optimized source, type inferred source (for given input types; it is a dynamic language), LLVM bytecode, and assembly. All visible and introspectable at runtime from either the REPL or scripts.

eru 13y ago

I am currently working with an in-house language that does only whole program analysis. If you have to be restricted to one or the other, you want separate compilation---the compiler times are just so horrible otherwise. (Optional whole program analysis compilation is fine, though.)