This is the mail archive of the cygwin 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


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


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