[Haskell-cafe] ANNOUNCE: ghc-gc-tune: a tool for analyzing the impact of GC flags

[Andrew Coppin]

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. (!)