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.
