Re: Where do I start if I would like help improve GHC compilation times?
> it would be quite helpful if `pretty` > gained a special-case for the infinite band-width case Absolutely +1 this. Not "pretty" but similar: https://github.com/jwaldmann/wl-pprint-text/commit/7843d96db57ab01c0be336a5be0d7bca61902005 - J.W. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: StablePtr / StableName ?
Dear Simon, thanks for looking into this. > is StableName in the inner loop? Yes. This application's inner loop uses a HashMap (StableName Expression) Int for memoization. This is the Tseitin transform: for each node, build a literal. Each node is stable-named. I guess the RTS's hashmap performance comes into play only when pointers are moved (in GC). The application's hashmap cost will dominate, because it's used more often. > You'd have to measure it. I did. It seems we're good on StableNames, and time goes elsewhere. https://github.com/ekmett/ersatz/issues/30#issuecomment-274775792 - Johannes. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
StablePtr / StableName ?
Dear ghc devs, would the StablePtr performance issue (slow hash table) https://ghc.haskell.org/trac/ghc/ticket/13165 also affect StableNames? Cf. https://github.com/ekmett/ersatz/issues/30 Could making 10^5 stable names, and accessing each just once, take noticeable time? Where would this show up in a profile? I guess there's no easy way to change the ersatz library (StableName this is the fundamental mechanism for detecting sharing) but if these issues are related, then ersatz provides a performance test case. Thanks, Johannes. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Measuring performance of GHC
Hi Ben, thanks,
> 4. run the build, `cabal configure --ghc-options="-p -hc" $args && cabal
> build`
cabal configure $args --ghc-options="+RTS -p -hc -RTS"
> You should end up with a .prof and .hp file.
Yes, that works. - Typical output starts like this
COST CENTRE MODULE %time %alloc
SimplTopBinds SimplCore 60.7 57.3
OccAnal SimplCore 6.06.0
Simplify SimplCore 3.00.5
These files are always called ghc.{prof,hp},
how could this be changed? Ideally, the output file name
would depend on the package being compiled,
then the mechanism could probably be used with 'stack' builds.
Building executables mentioned in the cabal file will
already overwrite profiling info from building libraries.
When I 'cabal build' the 'text' package,
then the last actual compilation (which leaves
the profiling info) is for cbits/cbits.c
I don't see how to build Data/Text.hs alone
(with ghc, not via cabal), I am getting
Failed to load interface for ‘Data.Text.Show’
- J.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Measuring performance of GHC
Hi, > ... to compile it with a profiled GHC and look at the report? How hard is it to build hackage or stackage with a profiled ghc? (Does it require ghc magic, or can I do it?) > ... some obvious sub-optimal algorithms in GHC. obvious to whom? you mean sub-optimality is already known, or that it would become obvious once the reports are there? Even without profiling - does hackage collect timing information from its automated builds? What needs to be done to add timing information in places like https://hackage.haskell.org/package/obdd-0.6.1/reports/1 ? - J.W. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Bikeshedding request for GHCi's :type
> .. :type should report the real type What about defaulting? Is it real? https://ghc.haskell.org/trac/ghc/ticket/11994 - J.W. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Proposal for removing transformers dependency
... a proposal for removing transformers dependency from ghc library. +1 - J.W. (I subscribed to this list just to send this one message ...) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
