Cygwin multithreading performance
Thu Jan 21 09:05:00 GMT 2016
Corinna Vinschen wrote:
> On Dec 8 22:10, Mark Geisert wrote:
>> I probably need to modify my stats gathering program to display the total
>> time spent waiting to make it more clear how things add up for each mutex
>> across the whole testcase. Again, these stats are not timing how long locks
>> are being held, but rather how long it takes just to acquire the lock.
> But acquiring a lock includes the time it actually has to wait for
> another thread holding the lock so you're measuring *also* the time
> locks are hold, just by another thread. locking and unlocking a
> pthread_mutex in Cygwin might be slower than using a critical section,
> but it's not *that* slow.
> The underlying point is, mutexes are not used as an end in itself. They
> guard a shared resource. What we ultimately need to know here is
> 1. What resource is it the pthread_mutexes are guarding?
> 2. Why does accessing the resource take so long that threads have to wait
> so long?
That sanity check was much appreciated. I worked a bit longer on this then set
it aside to wait for further inspiration while doing other work. No such
inspiration was forthcoming :) so I'll note what I found and close this off.
Bottom line, for the OP's original testcase having git do a repack of a locally
cloned Cygwin source tree, on my test system the 4 parallel threads were
spending no more than 6% of their time waiting for locks. That includes the
time those locks were held by some other thread. So this line of investigation
doesn't seem to answer the questions posed by the OP (i.e., why don't we see
~100% CPU utilization during a presumably CPU-bound operation, and why does
utilization seem so much lower with Cygwin git vs MinGW git). I could
speculate, but I won't.
I'm now looking into modifying the Cygwin profiling code to support the
profiling of multi-threaded applications. I'll post anew when I've got
something to report.
Thanks & Cheers,
More information about the Cygwin-developers