Kacper Michajlow writes:
> I recently noticed that Cygwin multithreading is very inefficient. I
> was repacking few git repositories and with Cygwin's git, it spawns
> threads but they are so badly synchronized that there is no speed gain
> over one thread and possible loose because of the overhead
On Dec 8 16:34, Corinna Vinschen wrote:
> On Dec 8 02:51, Mark Geisert wrote:
> > (Maybe cygwin-developers is a better list for this? It's pretty obscure.)
>
> Yes, cygwin-developers is fine since it's gory implementation details.
>
> > Here are some mutex lock stats I've been talking about pr
On Dec 8 02:51, Mark Geisert wrote:
> (Maybe cygwin-developers is a better list for this? It's pretty obscure.)
Yes, cygwin-developers is fine since it's gory implementation details.
> Here are some mutex lock stats I've been talking about providing. These are
> from the OP's original testcase
(Maybe cygwin-developers is a better list for this? It's pretty obscure.)
Here are some mutex lock stats I've been talking about providing. These are
from the OP's original testcase 'git repack -a -f' running over a clone of the
newlib-cygwin source tree. Run on a 2-core, 4-HT machine under
2015-12-06 9:02 GMT+01:00 Mark Geisert :
> Kacper Michajlow wrote:
>>
>> 2015-12-05 23:40 GMT+01:00 Mark Geisert :
>>>
>>> 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 re
Kacper Michajlow wrote:
2015-12-05 23:40 GMT+01:00 Mark Geisert :
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
2015-12-05 23:40 GMT+01:00 Mark Geisert :
> Kacper Michajlow wrote:
>>
>> 2015-12-05 11:51 GMT+01:00 Mark Geisert :
>>>
>>> Mark Geisert wrote:
>>> 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 ac
Kacper Michajlow wrote:
2015-12-05 11:51 GMT+01:00 Mark Geisert :
Mark Geisert wrote:
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 t
2015-12-05 14:07 GMT+01:00 Kacper Michajlow :
> 2015-12-05 11:51 GMT+01:00 Mark Geisert :
>> 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:
>> > Co
2015-12-05 11:51 GMT+01:00 Mark Geisert :
> 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 Ge
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 g
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, bu
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 k
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.
> >
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 m
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 in Cygwin
are probably the calls to
On Nov 21 01:21, Mark Geisert wrote:
> Kacper Michajlow wrote:
> >Thanks for reply. And sorry for being not specific enough before. 'git
> >gc' is a driver which runs various git command to do cleanup in
> >repository. Though I'm mostly concerned about the code I linked.
> >Instead of 'git gc' it i
Kacper Michajlow wrote:
Thanks for reply. And sorry for being not specific enough before. 'git
gc' is a driver which runs various git command to do cleanup in
repository. Though I'm mostly concerned about the code I linked.
Instead of 'git gc' it is better to test directly 'git repack -a -f'
and
2015-11-19 21:24 GMT+01:00 Mark Geisert :
> Kacper Michajlow wrote:
>>
>> I recently noticed that Cygwin multithreading is very inefficient. I
>> was repacking few git repositories and with Cygwin's git, it spawns
>> threads but they are so badly synchronized that there is no speed gain
>> over one
Kacper Michajlow wrote:
I recently noticed that Cygwin multithreading is very inefficient. I
was repacking few git repositories and with Cygwin's git, it spawns
threads but they are so badly synchronized that there is no speed gain
over one thread and possible loose because of the overhead. On my
Hello,
I recently noticed that Cygwin multithreading is very inefficient. I
was repacking few git repositories and with Cygwin's git, it spawns
threads but they are so badly synchronized that there is no speed gain
over one thread and possible loose because of the overhead. On my
machine I got 7-1
21 matches
Mail list logo
