3 ms·

Are we talking about optimisations now? Or still about a compilation? Optimisations are a totally different story. They can bring some complexity in, but the ni

by sklogic 10y ago

Are we talking about optimisations now? Or still about a compilation? Optimisations are a totally different story. They can bring some complexity in, but the nice part is that they're totally optional and not required for solving the problem.

hga 10y ago
Minimally acceptable optimizations, because if your implementation is too slow, they're not optional. The examples are legion; to go to another domain, look at one of the reasons the VLIW Itanium failed, except for some numeric code the compiler(s) couldn't schedule enough operations for those Very Long Instruction Words. (Perhaps a more primary reason was that x86 code ran too slow, denying customers an easy upgrade path that due to volume sales might have resulted in more effort being put into the VLIW compilers.)
- sklogic 10y ago
  Remember, we're not talking about high performance C compilers and all that here. We're talking about the programming paradigm where everything is a compiler. Network protocol parsing is a form of compilation, all file formats parsing is a form of compilation, reacting to the UI events is a form of a compilation, processing data in whatever ways is a form of a compilation. Yet, you can only invent any optimisations at all for a small subset of compiler transformations, so for most of the cases optimisation is just totally irrelevant. As for the minimally acceptable optimisations, they're all trivial anyway. What you'd normally expect to see in most of the IRs is: constant propagation/folding (trivial), ADCE (trivial), algebraic simplification (trivial, no matter how ugly it is in, say, instcombine pass in LLVM - they're just doing it wrong), partial evaluation (trivial), inlining (trivial), backtracking for the latter two (trivial, but rarely seen, most would resort to awfully complex heuristics instead), CSE (trivial), escape analysis (trivial). What is not trivial is the stuff you'd rarely need in the high level languages, and this paradigm is all about the high level languages indeed. Not trivial: loop fusion, polyhedral analysis, vectorisation, and, finally, everything related to the code generation: instruction selection, register allocation, instruction scheduling, VLIW packing, all that. You'll never see this stuff in any high level domain specific language - you already have a common low level backend to take care of it for you anyway.

by sklogic 10y ago

hga 10y ago

Minimally acceptable optimizations, because if your implementation is too slow, they're not optional. The examples are legion; to go to another domain, look at one of the reasons the VLIW Itanium failed, except for some numeric code the compiler(s) couldn't schedule enough operations for those Very Long Instruction Words. (Perhaps a more primary reason was that x86 code ran too slow, denying customers an easy upgrade path that due to volume sales might have resulted in more effort being put into the VLIW compilers.)

sklogic 10y ago
Remember, we're not talking about high performance C compilers and all that here. We're talking about the programming paradigm where everything is a compiler. Network protocol parsing is a form of compilation, all file formats parsing is a form of compilation, reacting to the UI events is a form of a compilation, processing data in whatever ways is a form of a compilation. Yet, you can only invent any optimisations at all for a small subset of compiler transformations, so for most of the cases optimisation is just totally irrelevant. As for the minimally acceptable optimisations, they're all trivial anyway. What you'd normally expect to see in most of the IRs is: constant propagation/folding (trivial), ADCE (trivial), algebraic simplification (trivial, no matter how ugly it is in, say, instcombine pass in LLVM - they're just doing it wrong), partial evaluation (trivial), inlining (trivial), backtracking for the latter two (trivial, but rarely seen, most would resort to awfully complex heuristics instead), CSE (trivial), escape analysis (trivial). What is not trivial is the stuff you'd rarely need in the high level languages, and this paradigm is all about the high level languages indeed. Not trivial: loop fusion, polyhedral analysis, vectorisation, and, finally, everything related to the code generation: instruction selection, register allocation, instruction scheduling, VLIW packing, all that. You'll never see this stuff in any high level domain specific language - you already have a common low level backend to take care of it for you anyway.