[GHC] #8231: Haskell's Run Time System doesn't save electricity

#8231: Haskell's Run Time System doesn't save electricity --------------------------+------------------------------------------------ Reporter: | Owner: UnixJunkie | Status: new Type: bug | Milestone: Priority: normal | Version: 7.4.1 Component: | Operating System: Linux Runtime System | Type of failure: None/Unknown Keywords: energy | Test Case: provided in the description saving | Blocking: Architecture: x86_64 | (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Someone provided me with a sequential implementation of the fibonacci function. Out of curiosity, it was compiled with -threaded and we played with the -N option of the runtime. That same someone noticed some suspicious behavior. I notice the same and so report about it: all cores specified by $np are fully used while there is no change in the wallclock time spent by the program. The code: --- {{{ import Text.Printf fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) i = 44 main = printf "n=%d => %d\n" i (fib i) }}} --- The build: --- {{{ ghc -threaded -O2 sequential_fib.hs }}} --- The run (on an eight cores machine), shell is Bash: --- {{{ for np in `seq 1 8` ; do time ./sequential_fib +RTS -N$np ; done }}} --- The output: --- {{{ n=44 => 701408733 real 0m10.838s user 0m10.817s sys 0m0.000s n=44 => 701408733 real 0m10.762s user 0m12.009s sys 0m9.165s n=44 => 701408733 real 0m10.774s user 0m24.846s sys 0m6.800s n=44 => 701408733 real 0m10.769s user 0m33.654s sys 0m8.413s n=44 => 701408733 real 0m11.222s user 0m47.427s sys 0m7.336s n=44 => 701408733 real 0m11.217s user 0m57.872s sys 0m7.752s n=44 => 701408733 real 0m11.208s user 1m9.172s sys 0m7.112s n=44 => 701408733 real 0m11.204s user 1m18.909s sys 0m7.768s }}} --- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8231 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8231: Haskell's Run Time System doesn't save electricity ------------------------------------------------+-------------------------- Reporter: UnixJunkie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Resolution: invalid | Keywords: energy Operating System: Linux | saving Type of failure: None/Unknown | Architecture: x86_64 Test Case: provided in the description | (amd64) Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => invalid Comment: This is because the parallel garbage collector is enabled by by default in the `-threaded` runtime, so even if your program is sequential the GC will use multiple cores. The fact your wallclock time doesn't go anywhere is thus not really surprising (it could even get worse, since threads may be crossing cache lines and cores in order to divide up the workload.) This is verifiable by running the application under `perf`: {{{ $ sudo perf record -ag -- ./8231 +RTS -N4 ... $ sudo perf report --stdio # # Samples: 194K of event 'cycles' # Event count (approx.): 142904701567 # # Overhead Command Shared Object Symbol # ........ ....... .................... ........................................ # 47.97% 8231 8231 [.] gcWorkerThread | --- gcWorkerThread 0x48fec0 0x1 ... }}} so `gcWorkerThread` is dominating here. If you link with `-rtsopts` and run your program with `+RTS -N -qb -qg`, your problem will go away and you'll only see one core in use. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8231#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC