This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][BZ #13065] New pthread_barrier algorithm to fulfill barrier destruction requirements.

On 12/23/2015 06:08 AM, Torvald Riegel wrote:
> On Tue, 2015-12-22 at 17:36 -0600, Paul E. Murphy wrote:
>> On 12/21/2015 02:34 PM, Torvald Riegel wrote:
>>> On Fri, 2015-12-18 at 17:47 -0600, Paul E. Murphy wrote:
>>>> Otherwise, it looks good to me, and seems like a good improvement to
>>>> have. Though, a more experienced reviewer may have more to say. This
>>>> is a bit more complicated than its predecessor. I'll test it on PPC
>>>> next week.
>>> Thanks!
>> Tested out fine on POWER8/PPC64LE.
> Thanks for testing!
>> I was curious what the performance
>> difference might be, so I slapped together the attached program. It
>> showed about 25% improvement with 64 thread/64 count/100000 iter input
>> on a 16 core machine.
> Nice.  I'd hope that when adding proper spinning, we should be able to
> improve performance / scalability further.  Do you perhaps want to add
> your test to our microbenchmarks?

I can, though it'll be on the backburner for a bit. It needs reworked to
test throughput as a meaningful iteration count is likely dependent on
the target system.

Do you have any thoughts on reasonable input values for different systems?
I.e maybe `grep -c proc /proc/cpuinfo` * 2?

Anyhow, I sent an RFC for the locking benchmarks I'd been working with, as
the question is applicable there too:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]