-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stack ghc
painfully slow
#1671
Comments
This is on our backlog but is unlikely to make the Creators Update. I know we're planning on looking at this soon though. For some context, I've looked at what causes this slowdown. For some reason stack has mapped an mind-bogglingly huge region of memory (I'm talking dozens of terabytes). When we fork we walk the entire address range to set up the new process's state. We have a design that should vastly speed this up, but we're approaching "pencils down" date for Creators Update. |
Gotcha, thanks for the context! |
Terabytes. That's awesome. Can't wait to see it in Resource Monitor. |
I assume they're doing it to manage their own heap. It's a big "MAP_NORESERVE" region which Linux seems to intelligently handle since "allocate all the things" seems to be a common paradigm. |
This seems to be the related discussion over at ghc ticket 9706 here, for what it is worth. Quoth:
So by my math that's 100×1012×104 = 1018 ≅ 260, which gets you in just under the wire. Or something. |
Adding @stehufntdev because he's been looking into this as well. |
I have encountered a similar bug with plain I found this slowdown by installing ghc v.8.0.2 (anything v.7.10 and below was fast) or by installing pandoc v.1.18 & above. See directions to install ghc or install pandoc for testing. If needed, I can provide a simple set of commands to reproduce. They both run similarly slow/delayed for me on both systems, but I have not seen reports from other *nix users seeing similar slowdowns, so I am guessing this is WSL related. |
This does not require Stack to replicate, GHC compiler alone is enough. I'm experiencing the same dreadfully slow compiler work. Besides, programs compiled with 8.0.x are slow too.
|
@benhillis: I believe you've bumped into GHC 8.0's new block-structured heap for 64-bit platforms. From the GHC 8.0.1 release notes:
|
@RyanGlScott - I suspect you are right. We need to modify the way our memory manager keeps track of uncommitted pages. I'd be very curious to see some performance measurements on how much better their allocator performs versus raw mmap / munmap calls. |
I was going to quip that curiosity too, but stuck with "awesome" instead. So you benchmark 8.0 and find out it is some percent faster than 7.0. Or just as fast, but simpler. But you end up demonstrating not much in the exercise. The Haskell guys seem okay with a hello world app asking for a terabyte of virtual memory. The Chakra guys seem okay with asking for 32GB to print hello, and if you are going to do that, [expletive], why not ask for a TB. I am still academically interested in how they arrived at 32GB. Why not 64GB or 128GB? Certainly not because "that would be crazy". It's working code. Smart people thought it was a good idea. Shrug. What you gonna do except sigh and re-work the memory manager. |
FWIW, Golang also does something similar by reserving a contiguous chunk of 512 GB of memory (see this comment). I'm certainly not qualified enough to say how they came up with that number, other than that it's a power of two and—to use their words—"512 GB (MaxMem) should be big enough for now". |
I have a workaround in the meantime, based on the discussion in https://ghc.haskell.org/trac/ghc/ticket/13304. It involves compiling your own GHC which does not utilize the large address space allocation, and then using that as the GHC for your stack builds. My workaround relies on then supplying that GHC as the common GHC for your projects. In my example, I will recompile GHC 8.0.2 using whatever ghc you already have on your system. I will also make sure that Cabal is installed using this GHC -- otherwise, installing other packages will fall under the same problem of slowness. I suggest cleaning your To fix, in the bash environment, I ran
Now you can do your You can monitor the VIRT usage with something like |
Don't you also have to recompile |
@sgraf812 In my use cases, I have not had to recompile stack. If I understand correctly, stack itself never builds anything, just calls the appropriate ghc to do so, through the project-level or system-level ghc (ghci, ghc-through-cabal, etc). This issue only appears during builds, so as long as the ghc that stack uses is fine, stack itself should be fine. Monitoring the path of the |
@pechersky This issue affects not only GHC 8, but also anything compiled with it ( |
@TerrorJack Thank you for clarifying that for me. My work-around fixes the " |
@pechersky Also, the |
@TerrorJack The |
@pechersky |
I have updated the code above to include your suggestion, @TerrorJack. According to https://docs.haskellstack.org/en/stable/faq/#what-is-the-relationship-between-stack-and-cabal, both the lib ( |
@Roman2K - Thanks for the information. I'm glad that it's much more usable for you, but we still do have a long way to go. We're looking into ways to improve base NTFS speed to help bring Windows filesystem performance more in line with Linux. |
I have anecdotally found the same problem with [edit] Another data point is |
We have improved mmap performance further in insider build 17063. I believe this makes stack ghc bearable to use now :). |
Thank you! I can attest to the significant improvement. |
Another anecdote: I opted into 17074 hoping to get acceptable working conditions, but Sorry for the negative report; keep doing great work, you'll get there. ❤️ |
In the hopes this may be useful to somebody here: I've set up a GHC PPA optimised for WSL (i.e. built with https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl It should merely be a matter of
and then simply prepending |
I would like to use VSCode on Windows + WSL + Stack ghci but due to this problem, it is really slow. I will check if recompiling a custom ghc without large address space allocation is better or not. Thanks @pechersky ! |
nb: GHC is "still slow" (as it were) but this was deemed fixedininsiderbuilds back in July 2017, and finally made its way into the April Update. |
1. Use cascadia code instead of Consolas. 2. All Windows versions before Windows Build 16215 is now EOL, so "use Windows 16215 or later" is now redundant. Reference: https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet 3. Use https://github.com/microsoft/terminal instead of wsltty. 4. `unsetopt BG_NICE` is not necessary anymore. 5. microsoft/WSL#1671 is fixed now. 6. Add comments to the steps which seem unnecessary
A brief description
Managing haskell projects with the
stack
tool is unusable due to how slow it is.Expected results
(from a laptop running ubuntu 16.04)
On desktop running WSL
15025
After installation, need stack to pull in a version of GHC. This should do the trick.
Generating the strace output (attached) inludes a few long (multi-second) waits on FUTEX_WAIT, as well as one for mmap.
Install stack with the standard instructions
stack_ghc_strace.txt
The text was updated successfully, but these errors were encountered: