"Boespflug, Mathieu" <m...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
