Re: Cygwin multithreading performance

[Mark Geisert <mark@maxrnd.com>]

Kacper Michajlow wrote:
> 2015-12-05 23:40 GMT+01:00 Mark Geisert <mark@maxrnd.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 the
>> 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...
> https://github.com/git/git/blob/master/compat/win32/pthread.h
> https://github.com/git/git/blob/master/compat/win32/pthread.c

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 :).

> 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.
> Cygwin:
> 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.
Thanks,

..mark

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple