[Top][All Lists]

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

bug#7073: no pthread_spinlock_t on Mac OS 10.6.4

From: Chen Guo
Subject: 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

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]