This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC 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: gomp barriers on aarch64


Hi Balázs,

I have tried the micro benchmark some more times both on gcc-5 and gcc-7. It
seems to have unstable results, which means either gcc-5 or gcc-7 may have bad
performance on my platform. And gcc-5 can sometimes do good job too. So
upgrading gcc doesn't actually solve the problem.

Cheers,

Baozi.

On Mon, Feb 27, 2017 at 08:27:17PM +0800, cbz wrote:
> On Mon, Feb 27, 2017 at 08:13:33PM +0800, cbz wrote:
> > [forget CC'ed to the list.]
> > 
> > On Mon, Feb 27, 2017 at 12:23:39PM +0100, Balázs Oroszi wrote:
> > > 2017-02-24 13:03 GMT+01:00 cbz <cbz@baozis.org>:
> > > > Hi,
> > > >
> > > > I have recently been running several programs (caffe, mxnet, openblas, blis...) on aarch64.  And I found performance regression when libgomp is used and OMP_NUM_THREADS is set to be >=2. Almost half of the execution time is consumed either in gomp_barrier_wait_end() or gomp_team_barrier_wait_end(). The version of libgomp I used is 5.3.1-14, which is shipped with Ubuntu 16.04. I'm wondering whether it is a known issue on aarch64. Or it might relate to some other factors of the system/hardware?
> > > 
> > > I also encountered this behavior some time ago, and I implemented my
> > > own simple threading to avoid this issue, so I second that.
> > > 
> > 
> > I have run the EPCC OpenMP micro-benchmark suite[1] to test the synchronization
> > performance for gcc-5.3.1 on aarch64. As what is expected, the results are
> > pretty bad, the overheads increase linearly as the number of threads grows.
> > (800ms overhead when OMP_NUM_THREADS is set to 2.) Then I have updated gcc
> > to the latest git version (7.0.1 20170226), which looks much more normal.
> > Though it is still not as good as x86, the overhead when OMP_NUM_THREADS is
> > set to 2 lows down to ~1ms, which is an acceptable result I think.
> 
> One exception seems to be 'ORDERED', which has worse performance when the
> number of thread is greater than 2.
> 
> Baozi.



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