
Jan-Willem Maessen
Absolutely. Good high-level thread support trumps anything provided by the operating system.
Unless you have more than one CPU...
Similar dramatic performance disparities have cropped up in the Java community. There are Java benchmarks which create thousands of threads; most implementations slow to a crawl when this happens, as the operating system collapses under the crushing load.
In particular, Linux will have a problem with thousands of *runnable* processes. There's some potentially nasty O(>n) complexities when processing the run queue, so while a couple of runnable processes is very fast, having lots is not. In practice, most processes are blocked on IO most of the time, so it seems it's only a problem for certain Java benchmarks. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

[CC stripped a bit] On Thu, Mar 01, 2001 at 07:58:26AM +0100, Ketil Malde wrote:
Jan-Willem Maessen
writes:
Absolutely. Good high-level thread support trumps anything provided by the operating system.
Unless you have more than one CPU...
No, even then, some high level thread support gains more than just mapping one thread > one OS process: Acquire (number_of_cpus), perhaps plus a few spare OS threads/processes and schedule your high level threads onto them. I've seen no OS that can handle 4 or 5 figure numbers of threads. However, Erlang (high level lightweight threads) or Concurrent Haskell in GHC's implementation *can* handle. In the latter case, with a memory overhead of about 1 or 2 KB per thread, in contrast to much more for OS threads (lemme see: a few 100 bytes for the in-kernel process structure, then one or two pages for the u-structure incl. per-process kernel-mode stack, in Linux those pages are wired into memory, in BSD they can be "swapped out" which is OTOH done only as last resort, and then thread-private stack, at least one page, sums up to at least 8 KB on i386).
[...]
Kind regards, Hannah.
participants (2)
-
Hannah Schroeter
-
Ketil Malde