[ ghc-Bugs-990844 ] conc004.hs mis-optimised (performance weirdness)

[SourceForge.net]

Bugs item #990844, was opened at 2004-07-14 13:06
Message generated for change (Comment added) made by simonmar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=990844&group_id=8032

Category: Compiler
Group: 6.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Remi Turk (remit)
Assigned to: Nobody/Anonymous (nobody)
Summary: conc004.hs mis-optimised (performance weirdness)

Initial Comment:
The following program
(fptools/testsuite/tests/ghc-regress/concurrent/should_run/conc004.hs)
runs about 10 times as slowly when compiled with -O,
both with 6.2.1 and with todays CVS.

% ghc -no-recomp conc004.hs
% time ./a.out
donereal 1.97
user 1.88
sys 0.05

% ghc -no-recomp -O conc004.hs
% time ./a.out                
donereal 21.69
user 20.40
sys 0.12


Strange enough, profiling completely reverses this:

% ghc -no-recomp -prof -auto-all conc004.hs   
% time ./a.out +RTS -p                     
donereal 20.23
user 17.81
sys 0.18

total time  =        2.10 secs   (105 ticks @ 20 ms)
total alloc = 1,116,017,312 bytes  (excludes profiling
overheads)

versus

% ghc -no-recomp -prof -auto-all -O conc004.hs
% time ./a.out +RTS -p
donereal 1.35
user 1.31
sys 0.01

total time  =        0.94 secs   (47 ticks @ 20 ms)
total alloc = 1,060,017,180 bytes  (excludes profiling
overheads)


Which seems pretty weird. Except that multithreaded
programs are well known for weird (timing) problems ;o)


module Main where

-- Test thread creation.
-- (from: Einar Wolfgang Karlsen
<ewk at Informatik.Uni-Bremen.DE>)

import Control.Concurrent

main :: IO ()
main = do
   mvar <- newEmptyMVar

   let 
   	spawner :: (IO () -> IO ThreadId) -> Int -> IO ()
   	spawner c 0 = putMVar mvar ()
   	spawner c n = do { c (spawner c (n-1)); return ()}

   spawner forkIO 1000000
   takeMVar mvar
   putStr "done"

----------------------------------------------------------------------

>Comment By: Simon Marlow (simonmar)
Date: 2004-08-09 14:06

Message:
Logged In: YES 
user_id=48280

The slowdown in the optimised version is all attributed to
GC time.  Why should the optimised version be doing more GC?
 Because very occasionally, one of the threads gets
pre-empted right after the forkIO but just before it
returns.  This thread hangs around on the run queue and
never gets scheduled because forkIO always places the new
thread at the head of the run queue.  These threads build up
in the heap and cause a lot of GC overhead.

I've fixed forkIO (and other thread creations) to be fairer:
new threads now go at the end of the run queue.  Now conc004
goes faster when optimised.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=990844&group_id=8032