This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin multithreading performance
- From: Kacper Michajlow <kasper93 at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 6 Dec 2015 21:56:26 +0100
- 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> <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>
2015-12-06 9:02 GMT+01:00 Mark Geisert <firstname.lastname@example.org>:
> Kacper Michajlow wrote:
>> 2015-12-05 23:40 GMT+01:00 Mark Geisert <email@example.com>:
>>> It looks like we're going to have to compare actual pthread_mutex_lock()
>>> implementations. Inspecting source is nice but I don't want to be
>>> chasing a
>>> mirage so I really hope there's a pthread_mutex_lock() function inside
>>> MinGW git you are running. gdb could easily answer that question. Could
>>> you please do an 'info func pthread_mutex_lock' after starting MinGW git
>>> under MinGW gdb with a breakpoint at main() (so libraries are loaded).
>> Hmm, thinking about it mingw doesn't have pthread implementation or
>> any wrapper for it. If someone needs pthread they would probably go
>> for pthreads-w32 implementation.
>> I started to wonder because I don't recall git would need pthreads to
>> compile on Windows. And indeed they have a wrapper for Windows API...
> OK, so git has its own pthread_mutex_lock/unlock ops which map to very
> light-weight critical section operations.
>> Though it is not really a matter that "native" git build is fast and
>> all, but that Cygwin's one really struggles if it comes to MT workload.
> In the worst cases I see using your testcase, about half the time the
> busiest locks are processed within 1 usec but there's a spectrum of longer
> latencies for the other half of the time. I don't know (yet) if that can be
> improved in Cygwin's more general implementation but at least the matter has
> now been brought to our attention :).
Yes, I can imagine, git's objects are very small so threading overhead
is very noticeable.
>> And this not only issue with git unfortunately. Download speeds are
>> also limited on Cygwin. I know POSIX compatibility layers comes with a
>> price but I would love to see improvements in those areas.
>> Receiving objects: 100% (230458/230458), 78.41 MiB | 1.53 MiB/s, done.
>> "native" git:
>> Receiving objects: 100% (230458/230458), 78.41 MiB | 18.54 MiB/s, done.
> You're asserting this additional testcase has the same cause. What is
> telling you that? And FTR what is the git command you are issuing? I can
> then do the lock latency analysis on this new testcase if warranted.
No, sorry, I mixed different things. It is just that I'm ruining both
git build lately and I wanted to share another issue before I forget
This was git clone command for some random repository from github.
There is a lot factors at hand here but the fact is with cygwin speed
is capped on 1.5MB/s and this is reproducible. This is probably also
related to the fact that git operates on large amount small object.
But this time it is single thread workload. I tried strace this, but
frankly I am not sure what to look for.
All in all I just want to bring those issues to your attention.
Whether it is fixable or not is another story. But we will not know
unless someone with required knowledge analyze it.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple