[ANNOUNCE] GHC 8.2.1 release candidate 1

[Boespflug, Mathieu]

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?

Best,

--
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>