<div dir="ltr">Hi Ben,<div><br></div><div>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:</div><div><br></div><div>1. debugging, possibly with gdb</div><div>2. stack traces on exceptions</div><div>3. stack sampling, which is a form of performance profiling.</div><div><br></div><div>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?</div><div><br></div><div>Best,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">--<br>Mathieu Boespflug<br>Founder at <a href="http://tweag.io" target="_blank">http://tweag.io</a>.</div></div>
<br><div class="gmail_quote">On 10 April 2017 at 21:28, Ben Gamari <span dir="ltr"><<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">"Boespflug, Mathieu" <<a href="mailto:m@tweag.io">m@tweag.io</a>> writes:<br>
<br>
> Hi Ben,<br>
><br>
> this is great news! I'm particularly keen on learning more about two points<br>
> you mentioned in your email:<br>
><br>
> * Compiler performance: do you have any numbers to quantify what 8.0 vs 8.2<br>
> is likely to look like?<br>
<br>
</span>I'm afraid the best I can provide at the moment is [1]. On closer<br>
inspection of these I'm a bit suspicious of the 8.0 numbers; I'll try to<br>
reproduce them (and characterize the current ghc-8.2 branch, which fixes<br>
a significant memory leak present in -rc1) shortly. That being said,<br>
there were a few major fixes in 8.2.<br>
<span class=""><br>
> How much has the work that's been done affect performance across the<br>
> board? Or are these mostly pathological cases (e.g. ghc --make with<br>
> high number of cores, large number of definitions in a module, large<br>
> amount of let nesting in definitions, etc)<br>
<br>
</span>The fixes span the gamut but I generally tried to concentrate on issues<br>
that looked like they might affect a large fraction of programs. I fixed<br>
at least one major regression present in 8.0 which significantly<br>
inflated allocations of typeclass instance matching. I've also done<br>
quite a bit of refactoring around our handling of names. These include<br>
improvements in interface file serialization efficiency and name lookup.<br>
These are just some of the major reworks; there are also numerous<br>
smaller fixes which I don't have time to cover here.<br>
<br>
Compilation performance has also generally improved as a result of some<br>
of the work in the simplifier. In particular, GHC now performs an early<br>
inlining phase which, quite surprisingly, tends to result in smaller<br>
programs earlier in simplification, reducing the amount of work that the<br>
compiler needs to carry out. Simon summarized some of his preliminary<br>
numbers here [2].<br>
<span class=""><br>
> * DWARF support: could you clarify at a very high-level what typical uses<br>
> cases can be expected to work and which ones won't? Would be eager to read<br>
> any resources you could point me at to help me understand what still needs<br>
> to be done on this front.<br>
><br>
</span>At this point if GHC compiles your program with -g you should have a<br>
pretty good assurance that the resulting DWARF information is<br>
reasonable. This means that users can use the ExecutionStack mechanism,<br>
RTS stack-trace functionality, and GDB without fear of the act of<br>
capturing a stacktrace leading to a crash.<br>
<br>
After starting to write more here, I realized that you will likely not<br>
be the last person to ask about this and updated the DWARF status page<br>
with additional discussion [3]. Let me know if you have any questions.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
[1] <a href="https://gist.github.com/bgamari/fbd3e55047bd041d8208ebe820c0f493" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>bgamari/<wbr>fbd3e55047bd041d8208ebe820c0f4<wbr>93</a><br>
[2] <a href="https://mail.haskell.org/pipermail/ghc-devs/2017-February/013818.html" rel="noreferrer" target="_blank">https://mail.haskell.org/<wbr>pipermail/ghc-devs/2017-<wbr>February/013818.html</a><br>
[3] <a href="https://ghc.haskell.org/trac/ghc/wiki/DWARF/Status" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/wiki/DWARF/Status</a><br>
</blockquote></div><br></div>