GNU bug report logs -
#7073
no pthread_spinlock_t on Mac OS 10.6.4
Previous Next
Reported by: "Gary V. Vaughan" <gary <at> gnu.org>
Date: Mon, 20 Sep 2010 05:52:01 UTC
Severity: normal
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 6 years and 201 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.