I ran into similar issue few years ago where lack of knowledge combined with large amount of fanboyism clouded someones mind. In a popular language comparisons site there was a threading benchmark. It was simple, just start 256 threads. Haskell beat C by far.
I did strace. The C benchmark actually spawned 256 threads and the Haskell one spawned 4. The response I got was that it's a builtin feature in Haskell that it uses lightweight threads internally. And because pthread doesn't do that you cannot do it in C and therefore the comparison is valid. Even though C doesn't have the concept of threading and everything must be done with an external library in anycase.
I could dig the old thread up but I've given up with those. I have nothing against high level languages, I use them a lot. However I find it very weird that some true fans feel the need of creating enormously biased benchmarks and then being proud that those benchmarks show that their favourite language is the best.
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.
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.
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.
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.
I did strace. The C benchmark actually spawned 256 threads and the Haskell one spawned 4. The response I got was that it's a builtin feature in Haskell that it uses lightweight threads internally. And because pthread doesn't do that you cannot do it in C and therefore the comparison is valid. Even though C doesn't have the concept of threading and everything must be done with an external library in anycase.
I could dig the old thread up but I've given up with those. I have nothing against high level languages, I use them a lot. However I find it very weird that some true fans feel the need of creating enormously biased benchmarks and then being proud that those benchmarks show that their favourite language is the best.