This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[PING][PATCH 5/6][BZ #11588] x86_64: Remove assembly implementations for pthread_cond_*
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: gratian dot crisan at ni dot com, libc-alpha at sourceware dot org, Darren Hart <dvhart at linux dot intel dot com>, Carlos O'Donell <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Jeff Law <law at redhat dot com>, Scot Salmon <scot dot salmon at ni dot com>, Siddhesh Poyarekar <spoyarek at redhat dot com>, Thomas Gleixner <tglx at linutronix dot de>, Clark Williams <williams at redhat dot com>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, Will Newton <will dot newton at linaro dot org>, gratian at gmail dot com
- Date: Sat, 20 Sep 2014 13:47:33 +0200
- Subject: [PING][PATCH 5/6][BZ #11588] x86_64: Remove assembly implementations for pthread_cond_*
- Authentication-results: sourceware.org; auth=none
- References: <OF6ABEE614 dot FAE80AD2-ON86257D0E dot 006B38F4-86257D0E dot 0070034A at ni dot com> <1406680317-20189-1-git-send-email-gratian dot crisan at ni dot com> <1406680317-20189-6-git-send-email-gratian dot crisan at ni dot com> <1407947800 dot 18963 dot 0 dot camel at triegel dot csb>
On Wed, Aug 13, 2014 at 06:36:40PM +0200, Torvald Riegel wrote:
> On Tue, 2014-07-29 at 19:31 -0500, gratian.crisan@ni.com wrote:
> > From: Gratian Crisan <gratian.crisan@ni.com>
> > C implementation, dual core Intel(R) Atom(TM) CPU E3825 @ 1.33GHz, gcc 4.7.3
> > pthread_cond_[test] iter/threads mean min max std. dev
> > ----------------------------------------------------------------------------
> > signal (w/o waiters) 1000000/100 95.077 90 28960 33.3326
> > broadcast (w/o waiters) 1000000/100 114.874 90 13820 78.6426
> > signal 1000000/1 6704.17 3510 49390 3537.21
> > broadcast 1000000/1 6726.35 3850 55430 3297.21
> > signal/wait 100000/100 16888.2 12240 6682020 15045.4
> > signal/timedwait 100000/100 19246.6 13560 6874950 15969.5
> > broadcast/wait 100000/100 17228.5 12390 6461480 14780.2
> > broadcast/timedwait 100000/100 19414.5 13910 6656950 15681.8
> >
> > Assembly implementation, dual core Intel(R) Atom(TM) CPU E3825 @ 1.33GHz
> > pthread_cond_[test] iter/threads mean min max std. dev
> > ----------------------------------------------------------------------------
> > signal (w/o waiters) 1000000/100 263.81 70 120171680 90138
> > broadcast (w/o waiters) 1000000/100 264.213 70 160178010 91861.4
> > signal 1000000/1 15851.7 3800 13372770 13889
> > broadcast 1000000/1 16095.2 5900 14940170 16346.7
> > signal/wait 100000/100 33151 7930 252746080 475402
> > signal/timedwait 100000/100 34921.1 10950 147023040 270191
> > broadcast/wait 100000/100 33400.2 11810 247194720 455105
> > broadcast/timedwait 100000/100 35022.1 13610 161552720 30328
>
> It seems the assembly implementation (or the runs where you used it)
> suffer from very large delays which seem to be outliers; max is several
> orders of magnitude higher. This seems to be the case on the Xeon too
> to some extent.
Did you do retesting? Also you could try to printf data to file and see
what happened.