Haskell GHC -s option explanation of TASKS metric

Question

When I give in GHC the -s option shows a TASKS metric as below which I don't know what it means:

   548,321,960 bytes allocated in the heap
      31,615,128 bytes copied during GC
       1,538,384 bytes maximum residency (17 sample(s))
          87,272 bytes maximum slop
              24 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0        54 colls,    54 par    0.044s   0.036s     0.0007s    0.0016s
  Gen  1        17 colls,    16 par    0.021s   0.018s     0.0010s    0.0023s

  Parallel GC work balance: 18.96% (serial 0%, perfect 100%)

  TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4)

  SPARKS: 8999 (8195 converted, 804 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.002s  (  0.001s elapsed)
  MUT     time   13.915s  (  3.857s elapsed)
  GC      time    0.066s  (  0.054s elapsed)
  EXIT    time    0.001s  (  0.007s elapsed)
  Total   time   13.984s  (  3.920s elapsed)

  Alloc rate    39,405,087 bytes per MUT second

  Productivity  99.5% of total user, 98.4% of total elapsed

I says TASKS:10 1 bound 9 peak workers. In the GHC manual I didn't find anything about TASKS.

Answer 1

Tasks are the GHC threaded runtime's internal structure for representing O/S threads, so a "task" is an O/S thread, more or less. This isn't precisely true. If a thread calls out to foreign code which then calls back into Haskell, an extra task gets allocated to the same O/S thread for the in-call, but it's true most of the time.

The threaded runtime very quickly starts a number of tasks (and so O/S threads) equal to twice the number of capabilities plus two, so even a main = putStrLn "Hello, World!" program run with -N4 will run with 10 tasks (and with -N32 with 66 tasks).

The runtime arranges to actually run CPU intensive code in tasks up to the number of capabilities, so even though with -N4, you might have 10 tasks, only four of them are going to be running user code while the rest are sleeping. Also, the RTS may allocate additional tasks with associated O/S threads beyond the initial number, if they are needed to max out the number of capabilities when enough CPU bound work is available and enough existing tasks are stuck in I/O or whatever.

To be honest, I don't think the statistic is very useful.