#3838: Performance issues with blackholes
--------------------------------------+-------------------------------------
Reporter: simonmar | Owner: simonmar
Type: bug | Status: closed
Priority: normal | Milestone: 6.14 branch
Component: Runtime System | Version: 6.12.1
Resolution: fixed | Keywords:
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: Runtime performance bug |
--------------------------------------+-------------------------------------
Changes (by simonmar):
* status: new => closed
* resolution: => fixed
Comment:
Patches committed today. The main ones are:
{{{
Mon Mar 29 07:44:56 PDT 2010 Simon Marlow <[email protected]>
* New implementation of BLACKHOLEs
This replaces the global blackhole_queue with a clever scheme that
enables us to queue up blocked threads on the closure that they are
blocked on, while still avoiding atomic instructions in the common
case.
Advantages:
- gets rid of a locked global data structure and some tricky GC code
(replacing it with some per-thread data structures and different
tricky GC code :)
- wakeups are more prompt: parallel/concurrent performance should
benefit. I haven't seen anything dramatic in the parallel
benchmarks so far, but a couple of threading benchmarks do improve
a bit.
- waking up a thread blocked on a blackhole is now O(1) (e.g. if
it is the target of throwTo).
- less sharing and better separation of Capabilities: communication
is done with messages, the data structures are strictly owned by a
Capability and cannot be modified except by sending messages.
- this change will utlimately enable us to do more intelligent
scheduling when threads block on each other. This is what started
off the whole thing, but it isn't done yet (#3838).
I'll be documenting all this on the wiki in due course.
Mon Mar 29 07:45:21 PDT 2010 Simon Marlow <[email protected]>
* Move a thread to the front of the run queue when another thread blocks
on it
This fixes #3838, and was made possible by the new BLACKHOLE
infrastructure. To allow reording of the run queue I had to make it
doubly-linked, which entails some extra trickiness with regard to
GC write barriers and suchlike.
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3838#comment:7>
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
