warren.henning:

On Mon, Jul 5, 2010 at 5:46 PM, Don Stewart wrote:

...

Feedback and patches welcome!

Interesting.

Could this be combined with the ACOVEA compiler flag thing you did a while back to produce a tool that would automatically improve performance of programs on a fixed architecture/environment just by recompiling and running it?

A bit longer term, but yes. So far I've got individual approaches for improving performance by finding: * inlining points * strictness flags * `par` points * LLVM flags * RTS GC flags They just need to be integrated into a coherent set of tools and written up :-) -- Don

Don Stewart wrote:

A bit longer term, but yes. So far I've got individual approaches for improving performance by finding:

* inlining points * strictness flags * `par` points * LLVM flags * RTS GC flags

They just need to be integrated into a coherent set of tools and written up :-)

I've always thought of compiler flags as being a fairly imprecise tool. For example, -funbox-strict-fields applies a particular transformation to EVERY STRICT FIELD IN THE ENTIRE PROGRAM. Which is fine if it's always a win - but then, if it were always a win, there wouldn't be a flag to turn it on. It would just be on permanently. ;-) I've always thought it's much better to write source annotations on the specific fields you want unboxed. You have more control this way. (And you don't have to remember any special compiler flags.) I'm talking about unboxing of course, but the same deal applies to inlining or any number of other source-level transformations that GHC can perform. Of course, presumably writing a program to frob all possible combinations of unboxing annotations would be a tad more tricky to write than one that just invokes ghc.exe with different CLI args. ;-) I'm also all for new ways of giving the compiler extra information. For example, it would be neat if there was some way to say "this function is cheap to (re)compute" or "this function is expensive to compute". Or hints like "it's OK to try to evaluate this function at compile-time; it's output will never be significantly larger than its input". Of course, implementing a pragma is one thing; somebody then has to write an optimisation pass that *does* something with this information. ;-) I don't know much about how LLVM works, but unless there's a specific set of flags that's clearly optimal in all cases, it would probably be useful to be able to tune flags per-function. (It would of course be far, far more useful to know *why* certain programs run faster with certain flags. Maybe the code that GHC feeds to LLVM can be tweaked or something...) As far as GC goes, I've often thought it would be nice to be able to somehow say "if THIS object dies, all THESE objects will die with it, so you can just go ahead and collect them all". The hard part, of course, is finding a way to implement this efficiently and make it so programmer error won't cause live objects to get collected. (!)