Programs may use kernel threads, lightweight threads; but coroutines, cooperative threads and other programs with custom schedulers will be listed as interesting alternative implementations.
However, the Haskell docs for Control.Concurrent note that in Haskell,
Concurrency is "lightweight", which means that both thread creation and context switching overheads are extremely low. Scheduling of Haskell threads is done internally in the Haskell runtime system, and doesn't make use of any operating system-supplied thread packages.
Which makes the comparison with a C implementation that uses kernel threads pretty unfair: presumably a C implementation that uses green threads / fibers would be much more competitive with the Haskell implementation. Comparing apples to oranges isn't very informative.
As an aside, choosing a language based on how fast its green thread implementation happens to be at passing tokens around a ring is utterly silly.
You can compile your app with the threaded runtime, in which case the threads are scheduled amongst the available CPU cores.
Edit: The benchmark in question does just this, with 5 cores. So while the docs you cut-n-pasted are technically accurate, they do not apply to this particular run of this particular benchmark.
Well, fair enough: presumably GHC is creating 5 kernel threads under the covers, whereas the C implementation creates 503 kernel threads. Therefore the C implementation incurs approximately 100x the context-switching overhead. Once again, apples to oranges.
the threads are scheduled amongst the available CPU cores.
Actually, the per-CPU idle stats suggest that the Haskell program ran entirely on a single CPU, so it wasn't actually utilizing all 4 cores anyway.
Programs may use kernel threads, lightweight threads; but coroutines, cooperative threads and other programs with custom schedulers will be listed as interesting alternative implementations.
However, the Haskell docs for Control.Concurrent note that in Haskell,
Concurrency is "lightweight", which means that both thread creation and context switching overheads are extremely low. Scheduling of Haskell threads is done internally in the Haskell runtime system, and doesn't make use of any operating system-supplied thread packages.
Which makes the comparison with a C implementation that uses kernel threads pretty unfair: presumably a C implementation that uses green threads / fibers would be much more competitive with the Haskell implementation. Comparing apples to oranges isn't very informative.
As an aside, choosing a language based on how fast its green thread implementation happens to be at passing tokens around a ring is utterly silly.