On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow wrote:

For loading large amounts of code into GHCi, you want to add -j<n> +RTS -A128m where <n> is the number of cores on your machine. We've found that parallel compilation works really well in GHCi provided you use a nice large allocation area for the GC. This dramatically speeds up working with large numbers of modules in GHCi. (500 is small!)

This is a bit of a thread hijack (feel free to change the subject), but I also have a workflow that involves loading a lot of modules in ghci (500-700). As long as I can coax ghci to load them, things are fast and work well, but my impression is that this isn't a common workflow, and specifically ghc developers don't do this, because just about every ghc release will break it in one way or another (e.g. by putting more flags in the recompile check hash), and no one seems to understand what I'm talking about when I suggest features to improve it (e.g. the recent msg about modtime and recompilation avoidance). Given the uphill battle, I've been thinking that linking most of those modules into a package and loading much fewer will be a better supported workflow. It's actually less convenient, because now it's divided between package level (which require a restart and relink if they change) and ghci level (which don't), but is maybe less likely to be broken by ghc changes. Also, all those loaded module consume a huge amount of memory, which I haven't tracked down yet, but maybe packages will load more efficiently. But ideally I would prefer to continue to not use packages, and in fact do per-module more aggressively for larger codebases, because the need to restart ghci (or the ghc API-using program) and do a lengthy relink every time a module in the "wrong place" changed seems like it could get annoying (in fact it already is, for a cabal-oriented workflow). Does the workflow at Facebook involve loading tons of individual modules as I do? Or do they get packed into packages? If it's the many modules, do you have recommendations making that work well and keeping it working? If packages are the way you're "supposed" to do things, then is there any idea about how hard it would be to reload packages at runtime? If both modules and packages can be reloaded, is there an intended conceptual difference between a package and an unpackaged collection of modules? To illustrate, I would put packages purely as a way to organize builds and distribution, and have no meaning at the compiler level, which is how I gather C compilers traditionally work (e.g. 'cc a.o b.o c.o' is the same as 'ar abc.a a.o b.o c.o; cc abc.a'). But that's clearly not how ghc sees it! thanks!

On Thu, Jun 7, 2018 at 2:48 PM, Bartosz Nitka wrote:

What version of GHC are you using? There have been some significant improvements like https://phabricator.haskell.org/rGHCb8fec6950ad99cbf11cd22698b8d5ab35afb828f, that only just made it into GHC 8.4.

I did in fact notice a very nice speedup in 8.4, this explains it. Finally I know who to thank for it! Thank you very much for that fix, it really makes a difference. Are there more goodies in the 8.0.2 facebook branch, or have they all made it into 8.4? As loaded modules seem to consume a lot of memory, I've considered trying GHC.Compact on them, but haven't looked into what that would entail. Have you considered something like that?

On 7 June 2018 at 22:25, Evan Laforge wrote:

On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow wrote:

...

For loading large amounts of code into GHCi, you want to add -j<n> +RTS -A128m where <n> is the number of cores on your machine. We've found that parallel compilation works really well in GHCi provided you use a nice large allocation area for the GC. This dramatically speeds up working with large numbers of modules in GHCi. (500 is small!)

This is a bit of a thread hijack (feel free to change the subject), but I also have a workflow that involves loading a lot of modules in ghci (500-700). As long as I can coax ghci to load them, things are fast and work well, but my impression is that this isn't a common workflow, and specifically ghc developers don't do this, because just about every ghc release will break it in one way or another (e.g. by putting more flags in the recompile check hash), and no one seems to understand what I'm talking about when I suggest features to improve it (e.g. the recent msg about modtime and recompilation avoidance).

Given the uphill battle, I've been thinking that linking most of those modules into a package and loading much fewer will be a better supported workflow. It's actually less convenient, because now it's divided between package level (which require a restart and relink if they change) and ghci level (which don't), but is maybe less likely to be broken by ghc changes. Also, all those loaded module consume a huge amount of memory, which I haven't tracked down yet, but maybe packages will load more efficiently.

But ideally I would prefer to continue to not use packages, and in fact do per-module more aggressively for larger codebases, because the need to restart ghci (or the ghc API-using program) and do a lengthy relink every time a module in the "wrong place" changed seems like it could get annoying (in fact it already is, for a cabal-oriented workflow).

Does the workflow at Facebook involve loading tons of individual modules as I do?

Yes, our workflow involves loading a large number of modules into GHCi. However, we have run into memory issues, which was the reason for the recent work on fixing this space leak: https://phabricator.haskell.org/D4659 As it is, this workflow is OK thanks to Bartosz' work on speedups for large numbers of modules, tweaking the RTS flags as I mentioned and some other fixes we've made in GHCi to avoid performance issues. (all of this is upstream, incidentally). There is probably low-hanging fruit to be had in reducing the memory usage of GHCi, nobody has really attacked this with the heap profiler for a while. However, I imagine at some point loading everything into GHCi will become unsustainable and we'll have to explore other strategies. There are a couple of options here: - pre-compile modules so that GHCi is loading the .o instead of interpreted code - move some of the code into pre-compiled packages, as you mentioned Cheers Simon

Or do they get packed into packages? If it's the many modules, do you have recommendations making that work well and keeping it working? If packages are the way you're "supposed" to do things, then is there any idea about how hard it would be to reload packages at runtime? If both modules and packages can be reloaded, is there an intended conceptual difference between a package and an unpackaged collection of modules? To illustrate, I would put packages purely as a way to organize builds and distribution, and have no meaning at the compiler level, which is how I gather C compilers traditionally work (e.g. 'cc a.o b.o c.o' is the same as 'ar abc.a a.o b.o c.o; cc abc.a'). But that's clearly not how ghc sees it!

thanks!

On 8 June 2018 at 19:18, Evan Laforge wrote:

On Fri, Jun 8, 2018 at 12:29 AM, Simon Marlow wrote:

...

heap profiler for a while. However, I imagine at some point loading everything into GHCi will become unsustainable and we'll have to explore other strategies. There are a couple of options here: - pre-compile modules so that GHCi is loading the .o instead of interpreted code

This is what I do, which is why I was complaining about GHC tending to break it. But when it's working, it works well, I load 500+ modules in under a second.

...

- move some of the code into pre-compiled packages, as you mentioned

I was wondering about the tradeoffs between these two approaches, compiled modules vs. packages. Compiled modules have the advantage that you can reload without restarting ghci and relinking a large library, but no one seems to notice when they break. Whereas if ghc broke package loading it would get noticed right away. Could they be unified so that, say, -package xyz is equivalent to adding the package root (with all the .hi and .o files) to the -i list? I guess the low level loading mechanism of loading a .so vs. a bunch of individual .o files is different.

I'm slightly surprised that it keeps breaking for you, given that this is a core feature of GHCi and we have multiple tests for it. You'll need to remind me - what were the bugs specifically? Maybe we need more tests. There really are fundamental differences in how the compiler treats these two methods though, and I don't see an easy way to reconcile them. Loading object files happens as part of the compilation manager that manages the compilations for all the modules in the current package, whereas packages are assumed to be pre-compiled and are linked on-demand after all the compilation is done. Cheers Simon

Am 09.06.2018 um 02:30 schrieb Evan Laforge : Currently -fdefer-type-errors is broken: https://ghc.haskell.org/trac/ghc/ticket/14963 This is not related to loading .o files, but ghci in general.

Which is a good indication that out CI story is still crap. Cheers, Manuel

Hi, Am Donnerstag, den 07.06.2018, 17:05 -0400 schrieb Ben Gamari:

How about on a new page (e.g. Building/InGhci) linked to from,

* https://ghc.haskell.org/trac/ghc/wiki/Building * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions (in the Tips & Tricks section)

It might also be a good idea to add a script to the tree capturing this pattern.

yes pretty please! Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Matthew Pickering writes:

I added the wiki page now: https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci

Do you mean just adding the .ghci file? It seems that this might be something that would be good to add to hadrian so that it can control the locations of the object files rather than splurging them over the build tree.

Just adding the .ghci file is a start. However, ideally it would be something that will be more resistant to bitrotting that we might even be able to test. For instance, a shell script or build system rule that can generate the .ghci file from GHC's cabal file and launch ghc --interactive. We could then test this during CI as I think there is enough interest in this workflow that we should really try to support it. Cheers, - Ben

Here is the diff adding ghci scripts and some related code changes: https://phabricator.haskell.org/D4904 This has made development iterations drastically quicker for me, which for me really lowers the friction to contribution. All of my diffs in the past week were developed by using ghc-in-ghci. -Michael On Wed, Jun 27, 2018 at 10:48 PM Michael Sloan wrote:

Wow! This is an absolute game changer for me with regards to ghc development. My usual workflow on large haskell projects is to use GHCI as much as possible for quick iterations. I'm really glad Csongor figured this out and that you sent an email about it.

I've been messing with this for a bit today, and after a few code changes, I can to load GHCI into GHCI!! For example, I can modify "ghciWelcomeMessage", reload, and enter into the nested ghci:

λ :r [491 of 492] Compiling GHCi.UI ( ../ghc/GHCi/UI.hs, tmp/GHCi/UI.o ) Ok, 492 modules loaded. λ :main -ignore-dot-ghci --interactive GHCi inception, version 8.7.20180627: http://www.haskell.org/ghc/ :? for help Prelude> unwords ["it", "works!"] "it works!" Prelude> :q Leaving GHCi. λ Prelude.unwords ["now,", "in", "outer", "GHCi"] "now, in outer GHCi"

I will be opening up a PR soon that makes this convenient, once I've polished it up.

-Michael On Wed, May 30, 2018 at 1:43 PM Matthew Pickering wrote:

...

Hi all,

Csongor has informed me that he has worked out how to load GHC into GHCi which can then be used with ghcid for a more interactive development experience.

1. Put this .ghci file in compiler/

https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c

2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp" from inside compiler/

It may take a while and require a little bit of memory but in the end all 500 or so modules will be loaded.

It can also be used with ghcid.

ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"

Hopefully someone who has more RAM than I.

Can anyone suggest the suitable place on the wiki for this information?

Cheers,

Matt _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs