Runtime performance degradation for multi-threaded C FFI callback

[Simon Marlow]

On 21/01/2012 15:35, Sanket Agrawal wrote:
> Hi Edward,
>
> I was just going to get back to you about it. I did find out that the
> issue was indeed one GHC thread dealing with 5 C threads for callback
> (1:5 mapping) - so, the C threads were blocking on callback waiting for
> the only GHC thread to be available. I updated the code to do 1:1
> mapping - 5 GHC threads for 5 C threads. That proved to be almost
> linearly scalable.

This is almost right, except that your callbacks are not waiting for a 
GHC *thread*, but what we call a "capability", which is roughly speaking 
"permission to execute Haskell code".  The +RTS -N option chooses the 
number of capabilities.

I expect that with -N1, your program is spending a lot of time just 
switching between the different OS threads.

It's possible that we could make the runtime more flexible here.  I 
recently made it possible to modify the number of capabilities at 
runtime, so it's conceivable that the runtime could automatically add 
capabilities if it is being called from multiple OS threads.

> John Latos suggested the above approach two days back, but I didn't get
> to test the idea until now.
>
> It doesn't seem to matter whether number of GHC threads are increased,
> if the mapping between GHC threads and C threads is not 1:1. I got 1:1
> mapping by doing forkIO for each C thread. Is it really possible to do
> 7:5 mapping (that is 7 GHC threads to choose from, for 5 C threads
> during callback)? I can't think of a way to do it. Not that I need it. I
> am just curious if that is possible.

Just think of +RTS -N7 as being 7 *locks*, not 7 threads.  Then it makes 
perfect sense to have 7 locks available for 5 threads.

Cheers,
	Simon



> Thanks,
> Sanket
>
> On Fri, Jan 20, 2012 at 11:16 PM, Edward Z. Yang <ezyang at mit.edu
> <mailto:ezyang at mit.edu>> wrote:
>
>     Hello Sanket,
>
>     What happens if you run this experiment with 5 threads in the C
>     function,
>     and have GHC run RTS with -N7? (e.g. five C threads + seven GHC
>     threads = 12
>     threads on your 12-core box.)
>
>     Edward
>
>     Excerpts from Sanket Agrawal's message of Tue Jan 17 23:31:38 -0500
>     2012 <tel:38%20-0500%202012>:
>      > 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-for-c-ffi-callback-when-pthreads-are-enabled
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users