[ANNOUNCE] GHC 8.2.1 release candidate 1

[Ben Gamari]

"Boespflug, Mathieu" <m at tweag.io> writes:

> Hi Ben,
>
> this is great news! I'm particularly keen on learning more about two points
> you mentioned in your email:
>
> * Compiler performance: do you have any numbers to quantify what 8.0 vs 8.2
> is likely to look like?

I'm afraid the best I can provide at the moment is [1]. On closer
inspection of these I'm a bit suspicious of the 8.0 numbers; I'll try to
reproduce them (and characterize the current ghc-8.2 branch, which fixes
a significant memory leak present in -rc1) shortly. That being said,
there were a few major fixes in 8.2.

> How much has the work that's been done affect performance across the
> board? Or are these mostly pathological cases (e.g. ghc --make with
> high number of cores, large number of definitions in a module, large
> amount of let nesting in definitions, etc)

The fixes span the gamut but I generally tried to concentrate on issues
that looked like they might affect a large fraction of programs. I fixed
at least one major regression present in 8.0 which significantly
inflated allocations of typeclass instance matching. I've also done
quite a bit of refactoring around our handling of names. These include
improvements in interface file serialization efficiency and name lookup.
These are just some of the major reworks; there are also numerous
smaller fixes which I don't have time to cover here.

Compilation performance has also generally improved as a result of some
of the work in the simplifier. In particular, GHC now performs an early
inlining phase which, quite surprisingly, tends to result in smaller
programs earlier in simplification, reducing the amount of work that the
compiler needs to carry out. Simon summarized some of his preliminary
numbers here [2].

> * DWARF support: could you clarify at a very high-level what typical uses
> cases can be expected to work and which ones won't? Would be eager to read
> any resources you could point me at to help me understand what still needs
> to be done on this front.
>
At this point if GHC compiles your program with -g you should have a
pretty good assurance that the resulting DWARF information is
reasonable. This means that users can use the ExecutionStack mechanism,
RTS stack-trace functionality, and GDB without fear of the act of
capturing a stacktrace leading to a crash.

After starting to write more here, I realized that you will likely not
be the last person to ask about this and updated the DWARF status page
with additional discussion [3]. Let me know if you have any questions.

Cheers,

- Ben

[1] https://gist.github.com/bgamari/fbd3e55047bd041d8208ebe820c0f493
[2] https://mail.haskell.org/pipermail/ghc-devs/2017-February/013818.html
[3] https://ghc.haskell.org/trac/ghc/wiki/DWARF/Status
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170410/d3554f27/attachment-0001.sig>