This is the mail archive of the cygwin-developers mailing list for the Cygwin project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Cygwin multithreading performance

From: Mark Geisert <mark at maxrnd dot com>
To: cygwin-developers at cygwin dot com
Date: Thu, 21 Jan 2016 01:05:11 -0800
Subject: Re: Cygwin multithreading performance
Authentication-results: sourceware.org; auth=none
References: <5662C199 dot 7040906 at maxrnd dot com> <CABPLAST5EnifrAQ2xKZmohKhyxQHh=K3x3DeCL+BTdHN8nN98w at mail dot gmail dot com> <566367C8 dot 5020703 at maxrnd dot com> <CABPLASSY3WWpHAeh=5gqRKdg85M8Wzkrq9qMaDhzhk2zvxgcOw at mail dot gmail dot com> <5663EB9A dot 40002 at maxrnd dot com> <CABPLASQZrDMnN32GG3-qRsnHhjsoroaY7ti1wx5uASDqdU7M+g at mail dot gmail dot com> <5666B61F dot 9050209 at maxrnd dot com> <20151208153438 dot GL22073 at calimero dot vinschen dot de> <20151208170244 dot GA10155 at calimero dot vinschen dot de> <5667C5D0 dot 1090504 at maxrnd dot com> <20151209092005 dot GA22479 at calimero dot vinschen dot de>

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 setit aside to wait for further inspiration while doing other work. No suchinspiration 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 locallycloned Cygwin source tree, on my test system the 4 parallel threads werespending no more than 6% of their time waiting for locks. That includes thetime those locks were held by some other thread. So this line of investigationdoesn'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 doesutilization seem so much lower with Cygwin git vs MinGW git). I couldspeculate, but I won't.

I'm now looking into modifying the Cygwin profiling code to support theprofiling of multi-threaded applications. I'll post anew when I've gotsomething to report.

Thanks & Cheers,

..mark

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]