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 <[email protected]> wrote: > "Boespflug, Mathieu" <[email protected]> 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 >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
