Adding a "release" setting in build.mk.sample (and some other build system questions)
Thomas Miedema
thomasmiedema at gmail.com
Fri Jan 29 16:44:56 UTC 2016
The default (and thus release) `SRC_HC_OPTS` uses `-H32m` (see mk/
config.mk.in).
Maybe you want to run some tests to see if it makes a difference on the
total build time?
I suggest also measuring without any `-H` flag, with just `-H` (see commit
below), and with `-H1G` or some other large value.
```
commit 323950933d3260503186b93e7a5a7bdaa4822c1b
Author: Simon Marlow <marlowsd at gmail.com>
Date: Mon Nov 30 15:18:36 2009 +0000
Implement a new heap-tuning option: -H
-H alone causes the RTS to use a larger nursery, but without exceeding
the amount of memory that the application is already using. It trades
off GC time against locality: the default setting is to use a
fixed-size 512k nursery, but this is sometimes worse than using a very
large nursery despite the worse locality.
Not all programs get faster, but some programs that use large heaps do
much better with -H. e.g. this helps a lot with #3061 (binary-trees),
though not as much as specifying -H<large>. Typically using -H<large>
is better than plain -H, because the runtime doesn't know ahead of
time how much memory you want to use.
Should -H be on by default? I'm not sure, it makes some programs go
slower, but others go faster.
```
On Fri, Jan 29, 2016 at 2:47 PM, Harry . <voldermort at hotmail.com> wrote:
> >
> https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds
> > https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration
>
> So the mysterious SRC_HC_OPTS = -O -H64m which appears in every build
> flavour isn't used for the release build?
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160129/c17ccafb/attachment.html>
More information about the ghc-devs
mailing list