3 ms·

How does a supercompiler differ to the optimisations that occur in a JIT compiler?

chrisseaton 9y ago
To be honest I think even the most sophisticated use of super-compilation - the partial evaluation described above - is really just a fancy way of saying inlining, constant folding and expression simplification.
- chriswarbo 9y ago
  Note that "inlining, constant folding and expression simplification" covers everything in functional programming :) Erlang isn't purely functional, since it has things like message sends. This project doesn't seem to handle such things properly :( > Something will happen if the supercompiled module contains side-effects such as message passing, and it will probably not be something good.
  - OoooooooO 9y ago
    Isn't the point of Erlang to use it's message system in most cases? If the supercompiler can't handle message passing then it can't handle ~98% of all Erlang code.
    - chrisseaton 9y ago
      Lots of optimisations don't apply in the presence of side-effects but are still useful.
willvarfar 9y ago
It's on a spectrum with it. JITs don't actually do much "optimization", because they need to be fast. It's subjective, but I'd say supercompiling is nearer to profile-guided whole-program optimization.
- exikyut 9y ago
  Huh. It would be kind of cool to hook a profiling execution tracer into a JIT to find hot paths, resolve that to the nearest "usefully supercompilable" code block (it sounds like supercompilation works best when fed whole programs, I'm not sure how much bigger-picture comprehension [large-scale] JITs have of program scope in practice) and then supercompile that in a CPU-throttled background thread. Thinking in the context of LLVM et al. I'm aware that JS engines do a "fast" compile designed to just generate code now within a few ms, and a fractionally slower compile that does do some optimizations and returns executable results within a few hundred ms. This could be a third optimization stage that takes 1 second, or maybe even 2 or 3, but produces really really good results. If this doesn't already exist - I don't know, so I can't really assume either way - it almost sounds like low hanging fruit, and a super fun project too.
  - willvarfar 9y ago
    Completely agree! There is plenty of unexplored space and tradeoffs across the spectrum :)

To be honest I think even the most sophisticated use of super-compilation - the partial evaluation described above - is really just a fancy way of saying inlining, constant folding and expression simplification.

chriswarbo 9y ago
Note that "inlining, constant folding and expression simplification" covers everything in functional programming :) Erlang isn't purely functional, since it has things like message sends. This project doesn't seem to handle such things properly :( > Something will happen if the supercompiled module contains side-effects such as message passing, and it will probably not be something good.
- OoooooooO 9y ago
  Isn't the point of Erlang to use it's message system in most cases? If the supercompiler can't handle message passing then it can't handle ~98% of all Erlang code.
  - chrisseaton 9y ago
    Lots of optimisations don't apply in the presence of side-effects but are still useful.

willvarfar 9y ago

It's on a spectrum with it. JITs don't actually do much "optimization", because they need to be fast. It's subjective, but I'd say supercompiling is nearer to profile-guided whole-program optimization.

exikyut 9y ago
Huh. It would be kind of cool to hook a profiling execution tracer into a JIT to find hot paths, resolve that to the nearest "usefully supercompilable" code block (it sounds like supercompilation works best when fed whole programs, I'm not sure how much bigger-picture comprehension [large-scale] JITs have of program scope in practice) and then supercompile that in a CPU-throttled background thread. Thinking in the context of LLVM et al. I'm aware that JS engines do a "fast" compile designed to just generate code now within a few ms, and a fractionally slower compile that does do some optimizations and returns executable results within a few hundred ms. This could be a third optimization stage that takes 1 second, or maybe even 2 or 3, but produces really really good results. If this doesn't already exist - I don't know, so I can't really assume either way - it almost sounds like low hanging fruit, and a super fun project too.
- willvarfar 9y ago
  Completely agree! There is plenty of unexplored space and tradeoffs across the spectrum :)