[GHC] #8623: Strange slowness when using async library with FFI callbacks
#8623: Strange slowness when using async library with FFI callbacks ------------------------------+-------------------------------------------- Reporter: | Owner: simonmar JohnWiegley | Status: new Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.6.3 Component: Runtime | Operating System: MacOS X System | Type of failure: Runtime performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I've attached a Haskell and a C file, when compiled as such: ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs SpeedTestC.c You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building with SPEED_BUG=0 produces an executable that takes more than a second to run, while building with SPEED_BUG=1 runs very quickly. I've also attached the Core for both scenarios. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): fwiw, I suspect some kind of lock contention issue, as the runtime goes down as soon as there's some delay involved (such as `putStr` or even using `threadDelay` which causes the thread to yield) as well as using more than one HEC via `+RTS -N2` -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by hvr: Old description:
I've attached a Haskell and a C file, when compiled as such:
ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs SpeedTestC.c
You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building with SPEED_BUG=0 produces an executable that takes more than a second to run, while building with SPEED_BUG=1 runs very quickly. I've also attached the Core for both scenarios.
New description: I've attached a Haskell and a C file, when compiled as such: {{{ ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs SpeedTestC.c }}} You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building with `SPEED_BUG=0` produces an executable that takes more than a second to run, while building with `SPEED_BUG=1` runs very quickly. I've also attached the Core for both scenarios. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by JohnWiegley): But {{{Control.Concurrent.yield}}} does not help, which I would have thought would also cause the thread to yield. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by JohnWiegley): I tried using just `forkIO` and `MVar`, but it does not exhibit the problem: {{{ main = do let test = mk'speed_test_cb (return ()) >>= speed_test test m <- newEmptyMVar _ <- forkIO $ test >> putMVar m () takeMVar m }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): doe the problem go away if the program is compiled in GHC HEAD using {{{ -fno-omit-yields}}} ? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by JohnWiegley): No, it makes no difference. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): So I understand why this happens, but I don't have a good idea for what to do about it yet. The problem is that each call into the RTS from the C function is very short, and when it is complete. the next call creates a new thread that goes to the back of the run queue. The main thread then gets a full time slice before the new thread gets to run. You can see the effect with `+RTS -C0.1` which halves the time slice length and halves the time to run the program. The new thread goes to the back of the queue to avoid possible starvation of other threads in the queue. Somehow we want to make the new thread inherit the rest of the timeslice from the previous thread, but I need to think some more about how we can do that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8623: Strange slowness when using async library with FFI callbacks -------------------------------------+------------------------------------- Reporter: | Owner: simonmar JohnWiegley | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8623#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC