#3758: `
-----------------------------+----------------------------------------------
Reporter: bos | Owner: simonmar
Type: bug | Status: new
Priority: high | Milestone: 6.12.2
Component: Runtime System | Version: 6.12.1
Resolution: | Keywords:
Difficulty: | Os: Linux
Testcase: | Architecture: x86_64 (amd64)
Failure: Runtime crash |
-----------------------------+----------------------------------------------
Changes (by simonmar):
* summary: Huge regression in concurrent app performance and reliability
under threaded runtime => `
Comment:
Part of the problem at least is this:
[[TicketQuery(id=3553|)]]
You're on a dual-core machine, running 3 threads (2 for the server and one
for the client, plus whatever other processes decide to wake up from time
to time). In 6.12.1 we enabled the parallel GC by default for young gen
collections. The parallel GC uses spinlocks for synchronisation, which do
not cope at all when one of the GC threads gets descheduled, which happens
quite a lot in this workload.
You can get back to the single-threaded performance by turning off the
parallel GC, with `+RTS -qg`.
The rule of thumb is that if you use `-N2`, you better be sure you have 2
CPUs available for the whole run of the program, otherwise performance
will go down the tubes. The work I'm doing on the GC at the moment will
eventually help here.
As for the absolute performance, clearly we could do a lot better. I've
attached a ThreadScope profile showing one of the gaps you can see if you
zoom in. This gap in particular I think is `select()` waking up, but
after select has woken a couple of Haskell threads it takes a little while
before we start running them. More investigation is needed.
I'm not closing the ticket yet because you also reported a deadlock. I
haven't been able to reproduce that yet.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3758#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
