Andrew Coppin schrieb:
> 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 w
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
On Tue, Jul 6, 2010 at 10:07 AM, 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 integr
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 ar
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
r
Don,
Thank you for a new tool and great blog post !
I will surely use it.
You might be interested by the experiments section of a paper that we
submitted to the Haskell Symposium with Simon Marlow and Satnam Singh :
http://membres-liglab.imag.fr/termier/HLCM/hlcm.pdf
We studied the impact of G
Inspired by a comment by Simon Marlow on Stack Overflow, about the time
and space tradeoffs we make with garbage collection, particularly with a
generational GCs, I wrote a small program, ghc-gc-tune, to traverse the
garbage collector variable space, to see the relationship between
settings and pr
