Hmm, this kind of sounds like GHC is assuming that it has control over all of the threads, and when this assumption fails bad things happen. (We use lightweight threads, and use the operating system threads that map to pthreads sparingly.) I'm sure Simon Marlow could give a more accurate assessment, however. Edward Excerpts from Sanket Agrawal's message of Tue Jan 17 23:31:38 -0500 2012:
I posted this issue on StackOverflow today. A brief recap:
In the case when C FFI calls back a Haskell function, I have observed sharp increase in total time when multi-threading is enabled in C code (even when total number of function calls to Haskell remain same). In my test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4, RHEL5, 12-core box):
- Single-threaded C function: call back Haskell function 5M times - Total time 1.32s - 5 threads in C function: each thread calls back the Haskell function 1M times - so, total is still 5M - Total time 7.79s - Verified that pthread didn't contribute much to the overhead by having the same code call a C function instead, and compared with single-threaded version. So, almost all of the increase in overhead seems to come from GHC runtime.
What I want to ask is if this is a known issue for GHC runtime? If not, I will file a bug report for GHC team with code to reproduce it. I don't want to file a duplicate bug report if this is already known issue. I searched through GHC trac using some keywords but didn't see any bugs related to it.
StackOverflow post link (has code and details on how to reproduce the issue): http://stackoverflow.com/questions/8902568/runtime-performance-degradation-f...