<div dir="ltr"><div>Added:</div><a href="https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c">https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c</a><br></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 5:15 PM, Austin Seipp <span dir="ltr"><<a href="mailto:austin@well-typed.com" target="_blank">austin@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I sometimes wonder if we should have a './performance' script or<br>
something in the root dir that does what ./validate does for the test<br>
suite: it always builds everything highly optimized (except perhaps<br>
GHC itself), and then immediately runs nofib (including parallel SMP<br>
tests, all that jazz) and sticks all that in a report you can keep<br>
around, and use with nofib-analyze later.<br>
<br>
But anyway, I agree with Simon that adding a 'bench' build type to<br>
mk/build.mk.sample is the way to go. For completeness, it's probably<br>
also worth adding a 'bench-llvm' type for the people who want to<br>
benchmark with the LLVM backend.*<br>
<br>
* We should actually refactor <a href="http://build.mk" target="_blank">build.mk</a> to not require duplication of<br>
every build type for these two ways, but I digress enough already.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Mar 10, 2014 at 10:54 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
> Add another build type for your use case.  The "quick" build means "build<br>
> everything as quickly as possible", which is useful for general development,<br>
> but not benchmarking.<br>
><br>
> Cheers,<br>
> Simon<br>
><br>
><br>
> On 08/03/2014 07:45, Johan Tibell wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> In my mind the "quick" build should be like the "perf" build, except<br>
>> building the stage2 compiler should be much faster. However, the perf<br>
>> build uses<br>
>><br>
>> GhcLibHcOpts = -O2<br>
>><br>
>> while the quick build uses<br>
>><br>
>> GhcLibHcOpts = -O -fasm<br>
>><br>
>> This means that if you're working on optimizing the generated code and<br>
>> are running benchmarks to verify your results, the quick build doesn't<br>
>> do the right thing.<br>
>><br>
>> Since the purpose of the quick build is to work on the stage2 compiler,<br>
>> would it make sense having it build the libraries in the same way as the<br>
>> perf build?<br>
>><br>
>> -- Johan<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
>><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards,<br>
<br>
Austin Seipp, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">http://www.well-typed.com/</a><br>
</font></span></blockquote></div><br></div>