bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4


From: Chen Guo
Subject: Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4
Date: Mon, 20 Sep 2010 14:38:12 -0700

Hi all,

First regarding mutexes on Macs, I suppose a performance hit with mutexes beats
no performance at all with missing spinlocks. And regarding "take more work," I
believe spinlocks and mutexes were basically interchangeable in terms
of functionality
in our sort algorithm; the work probably will be little more than a
few #ifdefs and a
s/pthread_mutex_t/pthread_spinlock_t/

How difficult would it be to implement a basic spinlock in gnulib,
though? Perhaps we
can implement that and fall back to it on MacOS X?


>> On a related note, I've been meaning to check
>> if mutexes in coreutils/sort are more stable
>> and/or fair to the system than spinlocks.
>
> They ought to be fairer, though I'd expect there to be a significant
> performance price in some cases.  I'm not sure what you mean
> by "stable" (surely this has nothing to do with stable sorting :-).
>

An example of the stability issues is be the hyperthreaded processor issue.
For example, when I was sorting on an i7 (4 cores, 8 logical), sort time with
threads > 4 had very high variance with spinlocks, but not with mutexes.

I do believe this particular issue is handled; I remember capping threads
to the number of physical cores on the system. Of course, there might be
other nasties that we just don't know about yet with spinlocks.


>> perhaps we should cap the
>> number of cores used to perhaps 8 given results like:
>> http://debbugs.gnu.org/cgi/bugreport.cgi?msg=49;filename=sort-amd-24way.png;att=1;bug=6600
>> We would allow increasing up to the number of cores
>> available on the system by user specified values
>> (which currently only support decreasing from #cores).
>
> That result depends on the particular benchmark and platform,
> of course.  Still, it might make sense to default to at most 8
> for now, as you suggest; the documentation should say that that
> default might change of course.
>

This is a good idea... I'm not sure how feasible this would be, but perhaps
we can benchmark some common server systems or some performance
outliers and define a custom max for these.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]