[Top][All Lists]
[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: |
Paul Eggert |
Subject: |
Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4 |
Date: |
Mon, 20 Sep 2010 11:00:33 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 |
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.
Re: no pthread_spinlock_t on Mac OS 10.6.4, Bruno Haible, 2010/09/20
Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4, Pádraig Brady, 2010/09/20