[ANNOUNCE] GHC 8.2.1 release candidate 1
m at tweag.io
Mon Apr 10 20:26:34 UTC 2017
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?
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
> > you mentioned in your email:
> > * Compiler performance: do you have any numbers to quantify what 8.0 vs
> > is likely to look like?
> I'm afraid the best I can provide at the moment is . 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 .
> > * 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
> > any resources you could point me at to help me understand what still
> > 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 . Let me know if you have any questions.
> - Ben
>  https://gist.github.com/bgamari/fbd3e55047bd041d8208ebe820c0f493
>  https://mail.haskell.org/pipermail/ghc-devs/2017-February/013818.html
>  https://ghc.haskell.org/trac/ghc/wiki/DWARF/Status
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs