Wed, 28 Feb 2001 10:11:01 -0500
Josef Svenningsson <email@example.com> wrote:
> One benchmark turned out to give pretty remarkable results. It's the
> producer/consumer benchmark. I suggest you all take a look at it. The
> haskell version is six (SIX!!!) times faster than the c version. Hey,
> what's going on here? I would really like to hear some comments from our
> dear implementors.
And Simon Peyton-Jones <firstname.lastname@example.org> replied:
> I guess GHC is fast because it's implementing lightweight
> threads inside a single OS thread.
Absolutely. Good high-level thread support trumps anything provided
by the operating system. I'd second Simon's guess that this was on
Linux or some other system where pthreads map one-to-one to OS
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. Those which
don't (IBM's Jalapeno, a research JVM, comes to mind) use this as a
*big* bragging point.
Unless you're mucking with thread priorities, mapping language-level
threads one-to-one to operating-system threads is a terrible idea.
Eager Haskell project