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@xxxxxxxxxx>: > > > > 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.
