Re: Setting Up a OpenBSD System for Building GHC Wiki Page

[Adam Steen]

Hi Sean

The more people using OpenBSD and GHC the better, please add as much
information as you think necessary.

Cheers
Adam

On Mon, Apr 10, 2017 at 12:26 PM, Sean Westfall  wrote:
> Hi Adam Steen,
> I just chatted with you on
> https://github.com/commercialhaskell/stack/issues/416, I just added so more
> info for the wxallowed step to your wiki page -- hope you don't mind. I'm
> gonna post something to this mailing list in a minute about the trouble I've
> been having with building GHC on openBSD 6.0.
>
> Thanks,
> Sean
>
> On Wed, Apr 5, 2017 at 8:04 PM, Adam Steen  wrote:
>>
>> Good Morning All
>>
>> Thanks for the replies
>>
>> @Karel
>> After more testing it looks like i can remove the python business.
>>
>> @Sergei and @Karel
>> libiconv is a prerequisite of ghc and is installed automatically, do
>> you think this should be explicit?
>>
>> @Matthias
>> I will have to have a read about branches and will update the wiki
>> shortly.
>>
>> Cheers
>> Adam
>>
>> On 6 April 2017 at 04:38, Matthias Kilian  wrote:
>> > Hi Adam,
>> >
>> > On Wed, Apr 05, 2017 at 03:39:18PM +0800, Adam Steen wrote:
>> >> I have created the Building/Preparation/OpenBSD Wiki Page, i have not
>> >> yet
>> >> link it to Building/Preparation
>> >>  page yet,
>> >> but
>> >> am looking for a review
>> >>
>> >> Setting Up a OpenBSD System for Building GHC
>> >> 
>> >
>> > Nice to see that some people actively work on ghc on OpenBSD (and
>> > apologies for me beeing such a slacker keeping the ghc package for
>> > OpenBSD up to date).
>> >
>> > FWIW, you don't have to pass the very exact package name to pkg_add,
>> > like 'autoconf-2.69p2' or ''automake-1.15p0'. There's a relatively new
>> > concept in pkg_tools called 'branches' (see pkg_add(1) manpage).
>> >
>> > You just have to replace the '-' separating the stem and the version by
>> > a '%', e.g.
>> >
>> > pkg_add autoconf%2.69 automake%1.15
>> >
>> > Then you'll get autoconf-2.69 and aotmake-1.15 regardless of what's the
>> > current REVISION (aka package patchleve) ot the package.
>> >
>> > Ciao,
>> > Kili
>>
>> On Thu, Apr 6, 2017 at 4:38 AM, Matthias Kilian 
>> wrote:
>> > Hi Adam,
>> >
>> > On Wed, Apr 05, 2017 at 03:39:18PM +0800, Adam Steen wrote:
>> >> I have created the Building/Preparation/OpenBSD Wiki Page, i have not
>> >> yet
>> >> link it to Building/Preparation
>> >>  page yet,
>> >> but
>> >> am looking for a review
>> >>
>> >> Setting Up a OpenBSD System for Building GHC
>> >> 
>> >
>> > Nice to see that some people actively work on ghc on OpenBSD (and
>> > apologies for me beeing such a slacker keeping the ghc package for
>> > OpenBSD up to date).
>> >
>> > FWIW, you don't have to pass the very exact package name to pkg_add,
>> > like 'autoconf-2.69p2' or ''automake-1.15p0'. There's a relatively new
>> > concept in pkg_tools called 'branches' (see pkg_add(1) manpage).
>> >
>> > You just have to replace the '-' separating the stem and the version by
>> > a '%', e.g.
>> >
>> > pkg_add autoconf%2.69 automake%1.15
>> >
>> > Then you'll get autoconf-2.69 and aotmake-1.15 regardless of what's the
>> > current REVISION (aka package patchleve) ot the package.
>> >
>> > Ciao,
>> > Kili
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>
> --
>
> Sean Westfall
> 2644 E. 4th St.
> Long Beach, CA 90802
> ph: (808) 281-4695
> em: sean.westf...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Setting Up a OpenBSD System for Building GHC Wiki Page

[Sean Westfall]

Hi Adam Steen,
I just chatted with you on
https://github.com/commercialhaskell/stack/issues/416, I just added so more
info for the wxallowed step to your wiki page -- hope you don't mind. I'm
gonna post something to this mailing list in a minute about the trouble
I've been having with building GHC on openBSD 6.0.

Thanks,
Sean

On Wed, Apr 5, 2017 at 8:04 PM, Adam Steen  wrote:

> Good Morning All
>
> Thanks for the replies
>
> @Karel
> After more testing it looks like i can remove the python business.
>
> @Sergei and @Karel
> libiconv is a prerequisite of ghc and is installed automatically, do
> you think this should be explicit?
>
> @Matthias
> I will have to have a read about branches and will update the wiki shortly.
>
> Cheers
> Adam
>
> On 6 April 2017 at 04:38, Matthias Kilian  wrote:
> > Hi Adam,
> >
> > On Wed, Apr 05, 2017 at 03:39:18PM +0800, Adam Steen wrote:
> >> I have created the Building/Preparation/OpenBSD Wiki Page, i have not
> yet
> >> link it to Building/Preparation
> >>  page yet,
> but
> >> am looking for a review
> >>
> >> Setting Up a OpenBSD System for Building GHC
> >> 
> >
> > Nice to see that some people actively work on ghc on OpenBSD (and
> > apologies for me beeing such a slacker keeping the ghc package for
> > OpenBSD up to date).
> >
> > FWIW, you don't have to pass the very exact package name to pkg_add,
> > like 'autoconf-2.69p2' or ''automake-1.15p0'. There's a relatively new
> > concept in pkg_tools called 'branches' (see pkg_add(1) manpage).
> >
> > You just have to replace the '-' separating the stem and the version by
> > a '%', e.g.
> >
> > pkg_add autoconf%2.69 automake%1.15
> >
> > Then you'll get autoconf-2.69 and aotmake-1.15 regardless of what's the
> > current REVISION (aka package patchleve) ot the package.
> >
> > Ciao,
> > Kili
>
> On Thu, Apr 6, 2017 at 4:38 AM, Matthias Kilian 
> wrote:
> > Hi Adam,
> >
> > On Wed, Apr 05, 2017 at 03:39:18PM +0800, Adam Steen wrote:
> >> I have created the Building/Preparation/OpenBSD Wiki Page, i have not
> yet
> >> link it to Building/Preparation
> >>  page yet,
> but
> >> am looking for a review
> >>
> >> Setting Up a OpenBSD System for Building GHC
> >> 
> >
> > Nice to see that some people actively work on ghc on OpenBSD (and
> > apologies for me beeing such a slacker keeping the ghc package for
> > OpenBSD up to date).
> >
> > FWIW, you don't have to pass the very exact package name to pkg_add,
> > like 'autoconf-2.69p2' or ''automake-1.15p0'. There's a relatively new
> > concept in pkg_tools called 'branches' (see pkg_add(1) manpage).
> >
> > You just have to replace the '-' separating the stem and the version by
> > a '%', e.g.
> >
> > pkg_add autoconf%2.69 automake%1.15
> >
> > Then you'll get autoconf-2.69 and aotmake-1.15 regardless of what's the
> > current REVISION (aka package patchleve) ot the package.
> >
> > Ciao,
> > Kili
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 

Sean Westfall
2644 E. 4th St.
Long Beach, CA 90802
ph: (808) 281-4695
em: sean.westf...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

[ANNOUNCE] GHC 8.2.1 release candidate 1

[Ben Gamari]

Hello everyone,

The GHC team is very pleased to announce the first candidate of the
8.2.1 release of the Glasgow Haskell Compiler. Source and binary
distributions are available at

https://downloads.haskell.org/~ghc/8.2.1-rc1/

This is the first of a few release candidates leading up the final 8.2.1
release. This release will feature,

  * A new type-indexed Typeable implementation

  * The long awaited Backpack

  * Deriving strategies for disambiguating DeriveAnyClass,
GeneralizedNewtypeDeriving, and stock mechanisms

  * Overloaded record fields

  * Improved compiler performance

  * Better code generation through more robust tracking of join points

  * Compact regions for more efficient garbage collection and serialization

  * Better support for machines with non-uniform memory architectures

  * More robust support for levity (e.g. RuntimeRep) polymorphism

  * A simple interface for streaming eventlog data from live processes

  * Further refinement of DWARF support

Unfortunately there are still a few known issues in this release,
including a few compiler panics (#13233, #13509) and a memory leak in
the simplifier (#13426) which may adversely affect heap sizes and
compilation time for some modules. This memory leak unfortunately made
it impossible to provide a 32-bit Windows distribution for this
candidate; this will be resolved in -rc2.

As always, please let us know if you have difficulty. Thanks to everyone
who has contributed to this release!

Happy testing,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Where do I start if I would like help improve GHC compilation times?

[Niklas Hambüchen]

I have some suggestions for low hanging fruits in this effort.

1. Make ghc print more statistics on what it spending time on

When I did the linking investigation recently
(https://www.reddit.com/r/haskell/comments/63y43y/liked_linking_3x_faster_with_gold_link_10x_faster/)
I noticed (with strace) that there are lots of interesting syscalls
being made that you might not expect. For example, each time TH is used,
shared libraries are loaded, and to determine the shared library paths,
ghc shells out to `gcc --print-file-name`. Each such invocation takes 20
ms on my system, and I have 1000 invocations in my build. That's 20
seconds (out of 2 minutes build time) just asking gcc for paths.

I recommend that for every call to an external GHC measures how long
that call took, so that it can be asked to print a summary when it's done.

That might give us lots of interesting things to optimize. For example,
This would have made the long linker times totally obvious.

At the end, I would love to know for each compilation (both one-shot as
used in ghc's build system, and `ghc --make`):

* What programs did it invoke and how long did they take
* What files did it read and how long did that take
* How long did it take to read all the `.hi` files in `ghc --make`
* High level time summary (parsing, typechecking, codegen, .hi files, etc)

That way we'll know at least what is slow, and don't have to resort to
strace every time in order to obtain this basic answer.

2. Investigate if idiotic syscalls are being done and how much

There's this concept I call "idiotic syscalls", which are syscalls of
which you know from before that they won't contribute anything
productive. For example, if you give a linker N many `-L` flags (library
dirs) and M many `-l` flags (library names to link), it will try to
`stat()` or `open()` N*M many files, out of which most are total
rubbish, because we typically know what library is in what dir.
Example: You pass `-L/usr/lib/opencv -L/usr/lib/imagemagick
-L/usr/lib/blas -lopencv -limagemagick -lblas`. Then you you will get
things like `open("/usr/lib/opencv/libimagemagick.so") = ENOENT` which
makes no sense and obviously that file doesn't exist. This is a problem
with the general "search path" concept; same happens for running
executables searching through $PATH. Yes, nonexistent file opens fail
fast, but in my typical ghc invocation I get millions of them (and we
should at least measure how much time is wasted on them), and they
clutter the strace output and make the real problems harder to investigate.
We should check if we can create ways to give pass those files that do
exist.

3. Add pure TemplateHaskell

It is well known that TH is a problem for incremental compilation
because it can have side effects and we must therefore be more
conservative about when to recompile; when you see a `[TH]` in your `ghc
--make` output, it's likely that time again.

I believe this could be avoided by adding a variant of TH that forbids
the use of the `runIO` function, and can thus not have side effects.

Most TH does not need side effects, for example any form of code
generation based on other data types (lenses, instances for whatever).
If that was made "pure TH", we would not have to recompile when inputs
to our TH functions change.

Potentially this could even be determined automatically instead of
adding a new variant of TH like was done for typed TH `$$()`, simply by
inspecting what's in the TH and if we can decide there's no `runIO` in
there, mark it as clean, otherwise as tainted.

4. Build ghc with `ghc --make` if possible

This one might be controversial or impossible (others can likely tell
us). Most Haskell code is built with `ghc --make`, not with the one-shot
compilation system + make or Hadrian as as done in GHC's build system.
Weirdly, often `ghc --make` scales much worse and has much worse
incremental recompilation times than the one-shot mode, which doesn't
make sense given that it has no process creation overhead, can do much
better caching etc. I believe that if ghc or large parts of it (e.g.
stage2) itself was built with `--make`, we would magically see --make
become very good, simply we make the right people (GHC devs) suffer
through it daily :D. I expect from this the solution of the `-j`
slowness, GHC overhead reduction, faster interface file loads and so on.

These are some ideas.

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Where do I start if I would like help improve GHC compilation times?

[David Feuer]

Be aware that some of the biggest performance problems with TH simply can't be 
fixed without changes to the TH language. For details, see Edward Yang's blog 
post: 
http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/
There was a Reddit thread discussing that post at 
https://www.reddit.com/r/haskell/comments/4tfzah/what_template_haskell_gets_wrong_and_racket_gets/

David FeuerWell-Typed, LLP
 Original message From: Alfredo Di Napoli 
 Date: 4/9/17  5:37 AM  (GMT-05:00) To: Ben Gamari 
 Cc: ghc-devs@haskell.org Subject: Re: Where do I start 
if I would like help improve GHC compilation times? 
Hey Ben,
as promised I’m back to you with something more articulated and hopefully 
meaningful. I do hear you perfectly — probably trying to dive head-first into 
this without at least a rough understanding of the performance hotspots or the 
GHC overall architecture is going to do me more harm than good (I get the 
overall picture and I’m aware of the different stages of the GHC compilation 
pipeline, but it’s far from saying I’m proficient with the architecture as 
whole). I have also read a couple of years ago the GHC chapter on the 
“Architeture of Open Source Applications” book, but I don’t know how much that 
is still relevant. If it is, I guess I should refresh my memory.
I’m currently trying to move on 2 fronts — please advice if I’m a fool flogging 
a dead horse or if I have any hope of getting anything done ;)
1. I’m trying to treat indeed the compiler as a black block (as you adviced) 
trying to build a sufficiently large program where GHC is not “as fast as I 
would like” (I know that’s a very lame definition of “slow”, hehe). In 
particular, I have built the stage2 compiler with the “prof” flavour as you 
suggested, and I have chosen 2 examples as a reference “benchmark” for 
performance; DynFlags.hs (which seems to have been mentioned multiple times as 
a GHC perf killer) and the highlighting-kate package as posted here: 
https://ghc.haskell.org/trac/ghc/ticket/9221 . The idea would be to compile 
those with -v +RTS -p -hc -RTS enabled, look at the output from the .prof file 
AND the `-v` flag, find any hotspot, try to change something, recompile, 
observe diff, rinse and repeat. Do you think I have any hope of making progress 
this way? In particular, I think compiling DynFlags.hs is a bit of a dead-end; 
I whipped up this buggy script which escalated into a Behemoth which is 
compiling pretty much half of the compiler once again :D
```#!/usr/bin/env bash
../ghc/inplace/bin/ghc-stage2 --make -j8 -v +RTS -A256M -qb0 -p -h \-RTS 
-DSTAGE=2 -I../ghc/includes -I../ghc/compiler -I../ghc/compiler/stage2 
\-I../ghc/compiler/stage2/build 
\-i../ghc/compiler/utils:../ghc/compiler/types:../ghc/compiler/typecheck:../ghc/compiler/basicTypes
 
\-i../ghc/compiler/main:../ghc/compiler/profiling:../ghc/compiler/coreSyn:../ghc/compiler/iface:../ghc/compiler/prelude
 
\-i../ghc/compiler/stage2/build:../ghc/compiler/simplStg:../ghc/compiler/cmm:../ghc/compiler/parser:../ghc/compiler/hsSyn
 
\-i../ghc/compiler/ghci:../ghc/compiler/deSugar:../ghc/compiler/simplCore:../ghc/compile/specialise
 \-fforce-recomp -c $@```
I’m running it with `./dynflags.sh ../ghc/compiler/main/DynFlags.hs` but it’s 
taking a lot to compile (20+ mins on my 2014 mac Pro) because it’s pulling in 
half of the compiler anyway :D I tried to reuse the .hi files from my stage2 
compilation but I failed (GHC was complaining about interface file mismatch). 
Short story short, I don’t think it will be a very agile way to proceed. Am I 
right? Do you have any recommendation in such sense? Do I have any hope to 
compile DynFlags.hs in a way which would make this perf investigation feasible?
The second example (the highlighting-kate package) seems much more promising. 
It takes maybe 1-2 mins on my machine, which is enough to take a look at the 
perf output. Do you think I should follow this second lead? In principle any 
50+ modules package I think would do (better if with a lot of TH ;) ) but this 
seems like a low-entry barrier start.
2. The second path I’m exploring is simply to take a less holistic approach and 
try to dive in into a performance ticket like the ones listed here: 
https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/czzq6an/Maybe
 some are very specific, but it seems like fixing small things and move forward 
could help giving me understanding of different sub-parts of GHC, which seems 
less intimidating than the black-box approach.
In conclusion, what do you think is the best approach, 1 or 2, both or none? ;)
Thank you!
Alfredo
On 7 April 2017 at 18:30, Alfredo Di Napoli  wrote:
Hey Ben,
thanks for the quite exhaustive reply! I’m on the go right now, but I promise 
to get back to you with a meaningful reply later this weekend ;)
Alfredo
On 7 April 2017 at 18:22, Ben 

Re: Where do I start if I would like help improve GHC compilation times?

[Reid Barton]

Building modules from GHC itself is a little tricky and DynFlags is
extra tricky since it is involved in import cycles. Here is what I do:

* Copy DynFlags.hs somewhere outside the tree (for your present
purposes, it is no longer part of the compiler, but just some module
to be provided as input).
* Get rid of all the {-# SOURCE #-} pragmas on imports to turn them
into ordinary, non-boot file imports.
* Build with ".../ghc/inplace/bin/ghc-stage2 DynFlags -package ghc
-I.../ghc/compiler/stage2" plus whatever other options you want (e.g.,
probably "-fforce-recomp -O +RTS -s" at a minimum). By using "-package
ghc" you compile DynFlags against the version of ghc that you have
just built.
* This will result in some type errors, because DynFlags imports some
functions that expect arguments of type DynFlags. (This relates to the
import cycles that we broke earlier.) Since you are building against
the version of those functions from the ghc package, they expect the
type ghc:DynFlags.DynFlags, but they are now receiving a value of type
DynFlags from the main package. This is no big deal, just insert an
unsafeCoerce wherever necessary (mostly in front of occurrences of
"dflags") to get the compiler to stop complaining.

This is not 100% faithful to the way DynFlags would actually be
compiled during a GHC build, but the advantage of this method is that
you don't have to worry about GHC doing any recompilation checking
between the copy of DynFlags that you are testing on and the
compiler's own modules.

Regards,
Reid Barton


On Sun, Apr 9, 2017 at 5:37 AM, Alfredo Di Napoli
 wrote:
> Hey Ben,
>
> as promised I’m back to you with something more articulated and hopefully
> meaningful. I do hear you perfectly — probably trying to dive head-first
> into this without at least a rough understanding of the performance hotspots
> or the GHC overall architecture is going to do me more harm than good (I get
> the overall picture and I’m aware of the different stages of the GHC
> compilation pipeline, but it’s far from saying I’m proficient with the
> architecture as whole). I have also read a couple of years ago the GHC
> chapter on the “Architeture of Open Source Applications” book, but I don’t
> know how much that is still relevant. If it is, I guess I should refresh my
> memory.
>
> I’m currently trying to move on 2 fronts — please advice if I’m a fool
> flogging a dead horse or if I have any hope of getting anything done ;)
>
> 1. I’m trying to treat indeed the compiler as a black block (as you adviced)
> trying to build a sufficiently large program where GHC is not “as fast as I
> would like” (I know that’s a very lame definition of “slow”, hehe). In
> particular, I have built the stage2 compiler with the “prof” flavour as you
> suggested, and I have chosen 2 examples as a reference “benchmark” for
> performance; DynFlags.hs (which seems to have been mentioned multiple times
> as a GHC perf killer) and the highlighting-kate package as posted here:
> https://ghc.haskell.org/trac/ghc/ticket/9221 . The idea would be to compile
> those with -v +RTS -p -hc -RTS enabled, look at the output from the .prof
> file AND the `-v` flag, find any hotspot, try to change something,
> recompile, observe diff, rinse and repeat. Do you think I have any hope of
> making progress this way? In particular, I think compiling DynFlags.hs is a
> bit of a dead-end; I whipped up this buggy script which escalated into a
> Behemoth which is compiling pretty much half of the compiler once again :D
>
> ```
> #!/usr/bin/env bash
>
> ../ghc/inplace/bin/ghc-stage2 --make -j8 -v +RTS -A256M -qb0 -p -h \
> -RTS -DSTAGE=2 -I../ghc/includes -I../ghc/compiler -I../ghc/compiler/stage2
> \
> -I../ghc/compiler/stage2/build \
> -i../ghc/compiler/utils:../ghc/compiler/types:../ghc/compiler/typecheck:../ghc/compiler/basicTypes
> \
> -i../ghc/compiler/main:../ghc/compiler/profiling:../ghc/compiler/coreSyn:../ghc/compiler/iface:../ghc/compiler/prelude
> \
> -i../ghc/compiler/stage2/build:../ghc/compiler/simplStg:../ghc/compiler/cmm:../ghc/compiler/parser:../ghc/compiler/hsSyn
> \
> -i../ghc/compiler/ghci:../ghc/compiler/deSugar:../ghc/compiler/simplCore:../ghc/compile/specialise
> \
> -fforce-recomp -c $@
> ```
>
> I’m running it with `./dynflags.sh ../ghc/compiler/main/DynFlags.hs` but
> it’s taking a lot to compile (20+ mins on my 2014 mac Pro) because it’s
> pulling in half of the compiler anyway :D I tried to reuse the .hi files
> from my stage2 compilation but I failed (GHC was complaining about interface
> file mismatch). Short story short, I don’t think it will be a very agile way
> to proceed. Am I right? Do you have any recommendation in such sense? Do I
> have any hope to compile DynFlags.hs in a way which would make this perf
> investigation feasible?
>
> The second example (the highlighting-kate package) seems much more
> promising. It takes maybe 1-2 mins on my machine, which is enough to take a
> look at the perf output. Do 

Re: Where do I start if I would like help improve GHC compilation times?

[Alfredo Di Napoli]

Hey Ben,

as promised I’m back to you with something more articulated and hopefully
meaningful. I do hear you perfectly — probably trying to dive head-first
into this without at least a rough understanding of the performance
hotspots or the GHC overall architecture is going to do me more harm than
good (I get the overall picture and I’m aware of the different stages of
the GHC compilation pipeline, but it’s far from saying I’m proficient with
the architecture as whole). I have also read a couple of years ago the GHC
chapter on the “Architeture of Open Source Applications” book, but I don’t
know how much that is still relevant. If it is, I guess I should refresh my
memory.

I’m currently trying to move on 2 fronts — please advice if I’m a fool
flogging a dead horse or if I have any hope of getting anything done ;)

1. I’m trying to treat indeed the compiler as a black block (as you
adviced) trying to build a sufficiently large program where GHC is not “as
fast as I would like” (I know that’s a very lame definition of “slow”,
hehe). In particular, I have built the stage2 compiler with the “prof”
flavour as you suggested, and I have chosen 2 examples as a reference
“benchmark” for performance; DynFlags.hs (which seems to have been
mentioned multiple times as a GHC perf killer) and the highlighting-kate
package as posted here: https://ghc.haskell.org/trac/ghc/ticket/9221 . The
idea would be to compile those with -v +RTS -p -hc -RTS enabled, look at
the output from the .prof file AND the `-v` flag, find any hotspot, try to
change something, recompile, observe diff, rinse and repeat. Do you think I
have any hope of making progress this way? In particular, I think compiling
DynFlags.hs is a bit of a dead-end; I whipped up this buggy script which
escalated into a Behemoth which is compiling pretty much half of the
compiler once again :D

```
#!/usr/bin/env bash

../ghc/inplace/bin/ghc-stage2 --make -j8 -v +RTS -A256M -qb0 -p -h \
-RTS -DSTAGE=2 -I../ghc/includes -I../ghc/compiler -I../ghc/compiler/stage2
\
-I../ghc/compiler/stage2/build \
-i../ghc/compiler/utils:../ghc/compiler/types:../ghc/compiler/typecheck:../ghc/compiler/basicTypes
\
-i../ghc/compiler/main:../ghc/compiler/profiling:../ghc/compiler/coreSyn:../ghc/compiler/iface:../ghc/compiler/prelude
\
-i../ghc/compiler/stage2/build:../ghc/compiler/simplStg:../ghc/compiler/cmm:../ghc/compiler/parser:../ghc/compiler/hsSyn
\
-i../ghc/compiler/ghci:../ghc/compiler/deSugar:../ghc/compiler/simplCore:../ghc/compile/specialise
\
-fforce-recomp -c $@
```

I’m running it with `./dynflags.sh ../ghc/compiler/main/DynFlags.hs` but
it’s taking a lot to compile (20+ mins on my 2014 mac Pro) because it’s
pulling in half of the compiler anyway :D I tried to reuse the .hi files
from my stage2 compilation but I failed (GHC was complaining about
interface file mismatch). Short story short, I don’t think it will be a
very agile way to proceed. Am I right? Do you have any recommendation in
such sense? Do I have any hope to compile DynFlags.hs in a way which would
make this perf investigation feasible?

The second example (the highlighting-kate package) seems much more
promising. It takes maybe 1-2 mins on my machine, which is enough to take a
look at the perf output. Do you think I should follow this second lead? In
principle any 50+ modules package I think would do (better if with a lot of
TH ;) ) but this seems like a low-entry barrier start.

2. The second path I’m exploring is simply to take a less holistic approach
and try to dive in into a performance ticket like the ones listed here:
https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/czzq6an/
Maybe some are very specific, but it seems like fixing small things and
move forward could help giving me understanding of different sub-parts of
GHC, which seems less intimidating than the black-box approach.

In conclusion, what do you think is the best approach, 1 or 2, both or
none? ;)

Thank you!

Alfredo

On 7 April 2017 at 18:30, Alfredo Di Napoli 
wrote:

> Hey Ben,
>
> thanks for the quite exhaustive reply! I’m on the go right now, but I
> promise to get back to you with a meaningful reply later this weekend ;)
>
> Alfredo
>
> On 7 April 2017 at 18:22, Ben Gamari  wrote:
>
>> Alfredo Di Napoli  writes:
>>
>> > Hey folks,
>> >
>> Hi Alfredo!
>>
>> First, thanks for writing. More eyes looking at GHC's compiler
>> performance is badly needed.
>>
>> > maybe I’m setting up for something too ambitious for me, but I would
>> like
>> > to take an active stance to the overlasting “GHC compilation times are
>> > terrible” matter, instead of simply stare at the screen with despair
>> > whenever GHC compiles a sufficiently large Haskell program ;)
>> >
>> > To make this even more interesting, I have never contributed to GHC
>> either!
>> > The max I have pushed myself into was 2 years ago when I successfully
>> built
>>