Added: https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c On Mon, Mar 10, 2014 at 5:15 PM, Austin Seipp wrote:

I sometimes wonder if we should have a './performance' script or something in the root dir that does what ./validate does for the test suite: it always builds everything highly optimized (except perhaps GHC itself), and then immediately runs nofib (including parallel SMP tests, all that jazz) and sticks all that in a report you can keep around, and use with nofib-analyze later.

But anyway, I agree with Simon that adding a 'bench' build type to mk/build.mk.sample is the way to go. For completeness, it's probably also worth adding a 'bench-llvm' type for the people who want to benchmark with the LLVM backend.*

* We should actually refactor build.mk to not require duplication of every build type for these two ways, but I digress enough already.

On Mon, Mar 10, 2014 at 10:54 AM, Simon Marlow wrote:

...

Add another build type for your use case. The "quick" build means "build everything as quickly as possible", which is useful for general development, but not benchmarking.

Cheers, Simon

On 08/03/2014 07:45, Johan Tibell wrote:

...

Hi,

In my mind the "quick" build should be like the "perf" build, except building the stage2 compiler should be much faster. However, the perf build uses

GhcLibHcOpts = -O2

while the quick build uses

GhcLibHcOpts = -O -fasm

This means that if you're working on optimizing the generated code and are running benchmarks to verify your results, the quick build doesn't do the right thing.

Since the purpose of the quick build is to work on the stage2 compiler, would it make sense having it build the libraries in the same way as the perf build?

-- Johan

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On 10/03/2014 19:58, Sergei Trofimovich wrote:

On Mon, 10 Mar 2014 18:59:38 +0100 Johan Tibell wrote:

...

Added: https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c

While at it:

...

SRC_HC_OPTS = ... -H64m

Just wondering: that '-H64m' is from some old times (pre 2007?). GHC seems to eat way more RAM nowadays. Is this bit relevant at all?

It still speeds up compilation a bit, but a larger -H value might be more appropriate for today's machines. Cheers, Simon