`stack ghc` painfully slow

[ezrosent]

• 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)

time stack ghc -- --version
The Glorious Glasgow Haskell Compilation System, version 8.0.1

real    0m0.124s                                                                                                                                           
user    0m0.092s                                                                                                                                               
sys     0m0.036s

• Actual results (with terminal output if applicable)
  On desktop running WSL

time stack ghc -- --version
The Glorious Glasgow Haskell Compilation System, version 8.0.1

real    0m50.520s
user    0m0.172s
sys     1m40.547s

• Your Windows build number
  15025
• Steps / All commands required to reproduce the error from a brand new installation
  After installation, need stack to pull in a version of GHC. This should do the trick.

stack setup
stack upgrade --install-ghc
time stack ghc -- --version

• Strace of the failing command
  Generating the strace output (attached) inludes a few long (multi-second) waits on FUTEX_WAIT, as well as one for mmap.
• Required packages and commands to install
  Install stack with the standard instructions

stack_ghc_strace.txt

[benhillis]

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.

[ezrosent]

Gotcha, thanks for the context!

[therealkenc]

Terabytes. That's awesome. Can't wait to see it in Resource Monitor.

[benhillis]

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.

[therealkenc]

This seems to be the related discussion over at ghc ticket 9706 here, for what it is worth. Quoth:

BTW, I found that I could mmap 100 TB with PROT_NONE (or even PROT_READ) and MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED with no measurable delay, and I can start 10000 such processes at once, so there doesn't seem to be any significant cost to setting up the page table mappings (at least on my system). Not sure why that is, exactly. The VSZ column in ps looks quite funny of course :)

So by my math that's 100×10¹²×10⁴ = 10¹⁸ ≅ 2⁶⁰, which gets you in just under the wire. Or something.

[benhillis]

Adding @stehufntdev because he's been looking into this as well.

[mckennapsean]

I have encountered a similar bug with plain ghc and pandoc. Really slow just to call and print out version info. Can confirm for slow-ring Insider Build & the Windows Preview v.15.15014 (using the free VM).

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.

[sukhmel]

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.

1. wget http://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-x86_64-deb8-linux.tar.xz
2. tar -xJf ghc-8.0.2-x86_64-deb8-linux.tar.xz
3. cd ghc-8.0.2
4. ./configure --prefix=/tmp/ghc
5. make install
6. time /tmp/ghc/bin/ghc -e 'putStrLn ""'

[RyanGlScott]

@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:

We have a shiny new two-step memory allocator for 64-bit platforms (see Trac #9706). In addition to simplifying the runtime system’s implementation this may significantly improve garbage collector performance. Note, however, that Haskell processes will have an apparent virtual memory footprint of a terabyte or so. Don’t worry though, most of this amount is merely mapped but uncommitted address space which is not backed by physical memory.

[benhillis]

@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.

[therealkenc]

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.