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
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/