https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103976
Bug ID: 103976
Summary: Very large overhead for if(false) openmp pragmas
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: nickpapior at gmail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
In OpenMP it may be beneficial to not use OpenMP in a region given that the
calculated workload is very small.
Something like this:
test.c:
#include <stdio.h>
int main(int narg, char args[]) {
float sum = 0.;
int i, j;
for ( i = 1 ; i<=100000000 ; i++) {
#ifdef _OPENMP
#pragma omp parallel for private(j) reduction(+:sum) if(0)
#else
// Just to have something that resembles the omp-if
if ( sum >= -1. ) {
#endif
for (j = 1 ; j<= 10 ; j++)
sum += 1./j;
#ifndef _OPENMP
}
#endif
}
printf("%15.7e\n", sum);
}
Never mind the faulty results, the idea is the culprit here.
I get the following timings:
gcc -O3 -o a.out test.c && time ./a.out
./a.out 1.60s user 0.00s system 99% cpu 1.604 total
gcc -O3 -o a.out test.c -fopenmp && time ./a.out
./a.out 9.13s user 4.62s system 99% cpu 13.743 total
Fortran has the same behaviour.
test.F90:
program main
real :: sum
integer :: i, j
sum = 0.
do i = 1, 100000000
#ifdef _OPENMP
!$OMP parallel do private(j) reduction(+:sum) if(.false.)
#else
! Just to have something that resembles the omp-if
if ( sum >= -1. ) then
#endif
do j = 1, 10
sum = sum + 1./j
end do
#ifdef _OPENMP
!$OMP end parallel do
#else
end if
#endif
end do
print *, sum
end program main
The complexity of adding the explicit if's was to emulate an if statement as
inserted in the openmp code. I know that openmp has lots more boiler plate
code, but this still seems awfully slow for me.
This came up in a sparse matrix solution library (MUMPS) which uses the #pragma
omp ... if(workload_huge) to decide on paths.
Let me know if anything else is necessary.
