"quick" vs "perf" builds

[Johan Tibell]

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


On Mon, Mar 10, 2014 at 5:15 PM, Austin Seipp <austin at well-typed.com> 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 <marlowsd at gmail.com> 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 at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140310/4dd3f250/attachment.html>