I've never worked on a project where my job was to create 256 threads. Instead, I would be tasked with processing lots of requests or datasets in parallel. If Haskell provides convenient and idiomatic ways to do this with lightweight threads that C does not, then C is effectively slower. If C has a commonly used and available library to implement this same approach - then maybe its faster. The whole point is we are comparing implementations of a programming task.

C doesn't impose a specific threading model. So a C threading benchmark is specific to the library you are using. And if you choose a heavyweight thread library to compare to a language which is not using heavyweight threads, it is not an apples to apples comparison. Arguably it could be, if C imposed a specific threading model, which it does not.

You are comparing implementations, not languages

Yes and that was my point. The benchmark is a comparison of implementations - compilers, run times and libraries. I am not sure how you would benchmark a language.

is there a nice lightweight threading library in c that distributes _many_ small threads on _few_ (not one) posix threads? if so: please tell me. i am genuinely interested.

You could use green threads in C but you'd also need asynchronous io to work with these green threads, and an ecosystem of libraries around it. Ghc has it therefore it makes sense to use its by default green threads. In c there is no standard ecosystem around green threads therefore it is harder to write the benchmarks that way.

This misses the point on why green threads are, and can be the default behavior in Haskell. It's because the purity allows it to be.

Sure you can make "green threads" in C, but you as the programmer must be very careful how you use these threads. You can't go accessing some global state (or performing many different side-effects) from them freely - so you must design your code to be as "purely functional" as possible to make any sense of them. The problem is when you come to use somebody elses code - how do you know it doesn't cause side-effects, if say, you only have the object and header files?

You don't, so at best you could "trial and error" until you find out that they're safe enough to use in green threads, but some bug might come back to bite you in the long run.

Haskell prevents this from ever being the case, because any function which does have side-effects must clearly express the fact in it's type signature. A green thread API can therefore specify the limitations on side-effects that may occur in it.

Purity has nothing to do with green threads. Many languages that doesn't have the concept of purity have green threads, like Erlang or Go. In fact, green threads are not a part of Haskell, but a part of the runtime. Purity is just a nice thing to have when working with threading or concurrent programs.

well. but a no-shared-writeable-data approach (as with erlang) certainly helps. and that comes for free with purity.

i don't know how go handles that though. i'd be surprised if this was as efficient as in erlang and haskell.

I disagree. Threads and green threads are not different in any way that is related to purity.

Haskell makes threads much more pleasant due to Haskell code generally being much more orthogonal. But even in C, it would make more sense to create green threads rather than actual threads (at least any thread beyond the first thread-per-core) in most settings you'd actually use threads for.

"Just start 256 threads" means you're testing the OS (or /maybe/ your runtime libraries) not the language.

I think that if you were comparing, say, erlang threads to Haskell threads then you would be comparing the languages because both of them have their own internal threads.

Because C has no such concept, and can only use hardware/OS threads, the comparison is moot.