This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin multithreading performance
- From: Mark Geisert <mark at maxrnd dot com>
- To: cygwin at cygwin dot com
- Date: Sat, 5 Dec 2015 02:51:05 -0800
- Subject: Re: Cygwin multithreading performance
- Authentication-results: sourceware.org; auth=none
- References: <CABPLASTtRK4mNxh0M_AnZgjJQ15kWPx+L=U=VCU3Wwi7jV_57A at mail dot gmail dot com> <564E3017 dot 90205 at maxrnd dot com> <CABPLASTLrH_udLuu2F-m5P6dkENW1Z4YHEudp4NG0-FGLJgPMg at mail dot gmail dot com> <5650379B dot 4030405 at maxrnd dot com> <20151121105301 dot GE2755 at calimero dot vinschen dot de> <5652C402 dot 7040006 at maxrnd dot com> <24780-1448274431-7444 at sneakemail dot com> <5653B52B dot 5000804 at maxrnd dot com> <20151126093427 dot GJ2755 at calimero dot vinschen dot de> <5656DDEF dot 9070603 at maxrnd dot com>
Mark Geisert wrote:
Corinna Vinschen wrote:
On Nov 23 16:54, Mark Geisert wrote:
John Hein wrote:
Mark Geisert wrote at 23:45 -0800 on Nov 22, 2015:
> Corinna Vinschen wrote:
> > On Nov 21 01:21, Mark Geisert wrote:
> [...] so I wonder if there's
> >> some unintentional serialization going on somewhere, but I
don't know yet
> >> how I could verify that theory.
> > If I'm allowed to make an educated guess, the big serializer
> > are probably the calls to malloc, calloc, realloc, free. We
> > need a new malloc implementation better suited to
Someone recently mentioned on this list they were working on porting
jemalloc. That would be a good choice.
Indeed; thanks for the reminder. Somehow I hadn't followed that thread.
Indeed^2. Did you look into the locking any further to see if there's
more than one culprit? I guess we've a rather long way to a "lock-less
But that is just groundwork to identifying which locks are suffering the
most contention. To identify them at source level I think I'll also
need to record the caller's RIP when they are being locked.
In the OP's very good testcase the most heavily contended locks, by far,
are those internal to git's builtin/pack-objects.c. I plan to show
actual stats after some more cleanup, but I did notice something in that
git source file that might explain the difference between Cygwin and
MinGW when running this testcase...
static pthread_mutex_t read_mutex;
#define read_lock() pthread_mutex_lock(&read_mutex)
#define read_unlock() pthread_mutex_unlock(&read_mutex)
static pthread_mutex_t cache_mutex;
#define cache_lock() pthread_mutex_lock(&cache_mutex)
#define cache_unlock() pthread_mutex_unlock(&cache_mutex)
static pthread_mutex_t progress_mutex;
#define progress_lock() pthread_mutex_lock(&progress_mutex)
#define progress_unlock() pthread_mutex_unlock(&progress_mutex)
#define read_lock() (void)0
#define read_unlock() (void)0
#define cache_lock() (void)0
#define cache_unlock() (void)0
#define progress_lock() (void)0
#define progress_unlock() (void)0
Is it possible the MinGW version of git is compiled with NO_PTHREADS
#defined? If so, it would mean there's no locking being done at all and
would explain the faster execution and near 100% CPU utilization when
running under MinGW.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple