3 ms·

I'm kind of curious how this would be practical, from a maintenance viewpoint. Would you then adopt the program's output back as your new "source"? Is the out

I'm kind of curious how this would be practical, from a maintenance viewpoint. Would you then adopt the program's output back as your new "source"? Is the output readable, maintainable? If you end up keeping your original source, and merely compile the output from this thing to get a fast executable, how do you debug stack traces when it crashes?

profquail 17y ago
I know of another startup who is close to launching a similar product: http://www.meta-alternative.net http://www.meta-alternative.net From speaking with the founders of that company, I understand that you keep your normal source (so it's easy to maintain), and only run the supercompiler/optimizer on your release builds (so you can ship fast executables to your customers.)
loup-vaillant 17y ago
The new source is not a source at all. You still continue to work on the old source. If your program has bugs you just encountered the "debug vs release" problem. Anyway, I can't see how this would be more useful than a classic optimizing compiler, except for languages like javascript, which is interpreted by third party clients.
- gwern 17y ago
  > Anyway, I can't see how this would be more useful than a classic optimizing compiler, except for languages like javascript, which is interpreted by third party clients. Pretty much every language can benefit from optimizations like constant folding and inlining (even C, yes); those techniques are subsets of partial evaluation, and partial evaluation is, apparently, a subset of supercompilation. And we should expect these general classes of optimization techniques to offer speedups. We know that classic optimizing compilers (GCC?) miss a lot of opportunities; this is especially obvious when you compare C and FORTRAN numeric performance - presumably all the FORTRAN optimizations could also be done in C by a sufficiently smart compiler (they're both Turing-complete languages, after all), but the C compilers can't reliably figure out when to do them. Even a language like Haskell which practically goes out of its way to let the compiler optimize however it wants can benefit: http://neilmitchell.blogspot.com/2007/12/supercompilation-for-haskell.html http://neilmitchell.blogspot.com/2007/12/supercompilation-fo... (Although I've read the paper and was confused; it looked more like partial evaluation to me - inlining and rewriting at compile-time until a fixed-point is reached - than this runtime supercompilation stuff.)

profquail 17y ago

I know of another startup who is close to launching a similar product: http://www.meta-alternative.net http://www.meta-alternative.net From speaking with the founders of that company, I understand that you keep your normal source (so it's easy to maintain), and only run the supercompiler/optimizer on your release builds (so you can ship fast executables to your customers.)

loup-vaillant 17y ago

The new source is not a source at all. You still continue to work on the old source. If your program has bugs you just encountered the "debug vs release" problem. Anyway, I can't see how this would be more useful than a classic optimizing compiler, except for languages like javascript, which is interpreted by third party clients.

gwern 17y ago
> Anyway, I can't see how this would be more useful than a classic optimizing compiler, except for languages like javascript, which is interpreted by third party clients. Pretty much every language can benefit from optimizations like constant folding and inlining (even C, yes); those techniques are subsets of partial evaluation, and partial evaluation is, apparently, a subset of supercompilation. And we should expect these general classes of optimization techniques to offer speedups. We know that classic optimizing compilers (GCC?) miss a lot of opportunities; this is especially obvious when you compare C and FORTRAN numeric performance - presumably all the FORTRAN optimizations could also be done in C by a sufficiently smart compiler (they're both Turing-complete languages, after all), but the C compilers can't reliably figure out when to do them. Even a language like Haskell which practically goes out of its way to let the compiler optimize however it wants can benefit: http://neilmitchell.blogspot.com/2007/12/supercompilation-for-haskell.html http://neilmitchell.blogspot.com/2007/12/supercompilation-fo... (Although I've read the paper and was confused; it looked more like partial evaluation to me - inlining and rewriting at compile-time until a fixed-point is reached - than this runtime supercompilation stuff.)