Richard,
In an effort to figure out why programs with lots of type families have
become so much slower over the last few GHC releases, I've been looking at
GHC Trac #12545 [1], which provides a very self-contained test case that
became considerably slower to compile from GHC 7.10 to 8.0. Thanks to this
test case, I found one of the sources of the slowdown: a single, very small
commit of yours [2].
What's baffling, though, is that I can't figure out why that commit makes
compilation so much slower. I tried making profiled builds of GHC before
and after that commit and attaching SCCs to the new code, but to my
surprise, their contribution to the overall compilation time was
negligible. So I'm out of ideas on what might be causing this.
The only hint I have is the output of -ddump-simpl-stats/-dshow-passes.
Before that commit, there's a point where the terms, types, and coercions
go up:
*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}):
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = False})
= {terms: 20,769, types: 1,157,897, coercions: 3,635,961}
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 44,081, types: 2,451,155, coercions: 9,802,016}
But after that commit, the terms and types jump up considerably higher!
*** Simplifier:
Result size of Simplifier
= {terms: 16,429, types: 864,761, coercions: 2,184,448}
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 87,357, types: 4,366,893, coercions: 10,008,352}
Here are the relevant bits from -ddump-simpl-stats. Before that commit:
150 PreInlineUnconditionally
40 PostInlineUnconditionally
220 UnfoldingDone
110 RuleFired
380 BetaReduction
After that commit:
306 PreInlineUnconditionally
160 PostInlineUnconditionally
360 UnfoldingDone
308 RuleFired
1238 BetaReduction
Does you know what might be going on here?
Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/12545
[2]
https://ghc.haskell.org/trac/ghc/changeset/1722fa106e10e63160bb2322e2ccb830…
Hello all,
Thanks for all the work that's put into GHC :)
I've tried to get into GHC development before, but I was unsuccessful,
mostly because I didn't dedicate enough time to understanding the problem
at hand & exploring the codebase.
I'd like to give it another shot. This time, I think I have a clear vision
of what I want to help with: Have haskell's error messages be easier to
read and understand.
1. Colors and layout to highlight important parts of the error messages
2. Clear formatting & naming of errors, so they're easily googleable,
stack-overflow able, etc.
3. better hints with error messages, and perhaps integrated lints(?).
4. I don't know if this is already possible, but allowing GHC errors to be
shipped off as JSON or something to interested tooling.
I saw this ticket on trac: https://ghc.haskell.org/trac/ghc/ticket/8809
I would like to take this up, but I'd like help / pointers and stuff. I
have GHC setup, I know how to use phabricator, but.. where do I start? :)
Thanks,
S~iddharth
--
Sending this from my phone, please excuse any typos!
This is a heads up that D3609[1], the first step toward implementing Trees
that Grow[2] for the hsSyn AST is about to land in master.
The key change is that it is replacing the HsSyn type parameter with one
that is an index into a set of type families, enabling the extension points
(for a future diff).
Any current work in progress branches will need a one-time search and
replace of all type parameters as follows
RdrName -> GhcPs
Name -> GhcRs
Var -> GhcTc
Id -> GhcTcId
Any code that makes use of the GHC API and needs to compile with earlier
versions too can do something like
#if MIN_VERSION_ghc(8,3,0)
type ParseI = GhcPs
type RenameI = GhcRn
type TypecheckI = GhcTc
#else
type ParseI = RdrName
type RenameI = Name
type TypecheckI = Var
#endif
and then replace the RdrName / Name / Var type params with ParseI / RenameI
/ TypecheckI.
A real world example is in ghc-exactprint[3]
Regards
Alan
[1] https://phabricator.haskell.org/D3609
[2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
[3]
https://github.com/alanz/ghc-exactprint/commit/6a6e3cdeb40f9623e9a7fc6f1be9…
1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn.
Definitely HsSyn. It’s big, riddled with extra info, and has many purposes for different people. Core is small, tight, nailed down. I don’t want to mess with it.
2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)?
I don’t think so. The issues are quite orthogonal, and no one (to my knowledge) has proposed any vaguely plausible change to variable bindings that would scale to what GHC does. In contrast, this stuff is “just” re-engineering.
Simon
From: David Feuer [mailto:david@well-typed.com]
Sent: 26 May 2017 01:11
To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alan & Kim Zimmerman <alan.zimm(a)gmail.com>; ghc-devs(a)haskell.org
Subject: RE: Trees that Grow in the hsSyn AST
I haven't looked in detail yet, but there seem to be good ideas. I have two questions:
1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn.
2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)?
David Feuer
Well-Typed, LLP
-------- Original message --------
From: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>>
Date: 5/25/17 6:48 PM (GMT-05:00)
To: Alan & Kim Zimmerman <alan.zimm(a)gmail.com<mailto:alan.zimm@gmail.com>>, ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>
Subject: RE: Trees that Grow in the hsSyn AST
Folks
Do take a look at this:
· We propose to re-engineer HsSyn itself. This will touch a lot of code.
· But it’s very neat, and will bring big long-term advantages
· And we can do it a bit at a time
The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details.
It’s entirely an internal change, not a change to GHC’s specification, so it’s independent of the GHC proposals process. But I’d value the opinion of other GHC devs.
Alan has done a prototype first step, which worked out rather well. Rather than having
HsExpr Id
(which we all know means “HsExpr after the typechecker” but tha’s a bit inexplicit, we have
HsExpr GhcTc
meaning “HsExpr after GHC’s Tc pass”. In some ways this is quite superficial, but it unlocks the Trees That Grow machiney.
Please ask questions etc. Alan and Shayan can record the answers in the wiki. I’m inclined to go ahead with this, so yell soon if you disagree.
Simon
From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 24 May 2017 22:52
To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>
Subject: Trees that Grow in the hsSyn AST
Hi all
You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year.
Based on the following mandate
> As in my previous email to Shayan (attached). Wiki page, describe goals, design,
> approach. Point to prototype implementation. Seek comments. You can say that
>I am supportive!
>
> Simon
We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3].
Please take a look and provide feedback.
Regards
Alan
[1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jucs.or…<http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf…>>
[2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
[3] https://phabricator.haskell.org/D3609
