GNU bug report logs - #7073
no pthread_spinlock_t on Mac OS 10.6.4

Previous Next

Full log

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> CS.UCLA.EDU>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Chen Guo <chen.guo.0625 <at> gmail.com>, bug-gnulib List <bug-gnulib <at> gnu.org>,
	bug-coreutils <at> gnu.org, "Gary V. Vaughan" <gary <at> gnu.org>
Subject: Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4
Date: Mon, 20 Sep 2010 11:00:33 -0700

On 09/20/10 02:33, Pádraig Brady wrote:
> 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 :-).

It's a bit tricky, as some users prefer performance, others fairness,
and the default can't satisfy everybody.

> 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.

Another thought: the syntax for --parallel might be generalized
to allow for fancier heuristics, e.g.:

	--parallel=50%

would mean to use at most half the processors.  This particular
syntax would be similar to how --buffer-size acts.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.