Re: [RFC] Avoid unnecessary futex_wake syscalls when all threads are busy waiting

[Tobias Burnus <burnus at net-b dot de>]

Jakub Jelinek wrote:
> Tested with libgomp testsuite and looked at performance numbers of Sho's
> omp_fib.c and libgomp.c/sort-1.c, unfortunately the differences looked to be
> in the noise.  But, e.g. on omp_fib.c strace -f shows that the number of
> futex FUTEX_WAKE syscalls went down a lot (from ~ 75000 for omp_fib 32 down
> to ~ 50 with the default wait policy, of course for OMP_WAIT_POLICY=passive
> it remained roughly the same).

I have tested the patch on an Intel(R) Xeon(R) CPU X5570  @ 2.93GHz  (2x 
Quad with hypherthreading) with SUSE Linux Enterprise Server 11 
(x86_64), PATCHLEVEL = 1 and GNU C Library stable release version 2.11.1.

GCC 4.7.0 20110714 [trunk revision 176260] flags: -Ofast -march=native 
-funroll-loops -flto -fwhole-program

Tested with four programs (in different variations) of NANOS's OpenMP 
task (!) test suite, available at 
http://nanos.ac.upc.edu/content/barcelona-openmp-task-suite

I always did 3 runs with the original libgomp.so and three with the 
patched one, taking the average of those runs. The columns are: Average 
run time (old), relative speed up to serial version, average run time 
(patched), speedup to the serial version, ratio (old)/(patched) in per cent.

Thus, the per-cent number is the crucial number - and the higher the 
better for this patch.

FFT and health profit a lot from the patch - especially for with many 
threads; alignment is in the noise. Taking the % number, summing it up 
and dividing it by the number of runs gives: 102.2%, which indicates a 
~2% performance gain.

Thanks for the patch Jakub!

Tobias

PS: I have repeated the FFT test cases to see how reliable the numbers are.

Attachment: omp.txt
Description: Text document