This is the mail archive of the libc-alpha@sourceware.org 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 Wed, 2015-12-23 at 09:17 -0600, Paul E. Murphy wrote:
> 
> 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?

As many threads as cores is probably a good measurement, as is a
one-thread test to get the single-thread overhead.  More tests with
thread counts inbetween those two could be useful as well to catch
scalability issues.

I'm not sure cores*2 is a good test.  We could do that to cover
oversubscribed systems (ie, threads > ("logical") cores) a bit and catch
performance pathologies there, but I don't think we should give
workloads with oversubscription a lot of weight; if one oversubscribes
and then uses barriers or locks, there will likely be performance
problems that a good barrier/lock/... can't fix completely.


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