[ANNOUNCE] GHC 8.2.1 release candidate 1

Boespflug, Mathieu m at tweag.io
Mon Apr 10 20:26:34 UTC 2017

Hi Ben,

thank you for this summary. The DWARF status page is helpful. Something was
unclear to me though. There are three main potential use cases for DWARF
that I see:

1. debugging, possibly with gdb
2. stack traces on exceptions
3. stack sampling, which is a form of performance profiling.

Forgive me for these naive questions, but... Is (1) possible at all at this
point? If I compile GHC with all the right options as explained in the
status page, do I magically get backtraces associated to all my exceptions?
What should I do to get those? It's my understanding that (3) is possible
and works fine, even when FFI code is invoked, but slower than for C
programs due to running user-level code to inspect the stack for each
sample. Is that right?


Mathieu Boespflug
Founder at http://tweag.io.

On 10 April 2017 at 21:28, Ben Gamari <ben at well-typed.com> wrote:

> "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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170410/ceebe05b/attachment.html>

More information about the ghc-devs mailing list