https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115367
--- Comment #2 from PierU <comptes at ugo235 dot fr> ---
I can confirm it's really dynamic, i.e. the number of threads can change each
time a parallel region is started. I tested with this Fortran toy example:
```
program p
use omp_lib
implicit none
real, allocatable :: x(:,:)
integer :: i, n = 1000
call omp_set_dynamic(.true.)
allocate( x(n*n,n) )
do
!$OMP PARALLEL
!$OMP SINGLE
write(*,"(I3)",advance='no') omp_get_num_threads()
!$OMP END SINGLE
!$OMP DO
do i = 1, n
x(:,i) = cos(x(:,i))
end do
!$OMP END DO
!$OMP SINGLE
write(*,*) " ", x(n*n/2,n/2)
!$OMP END SINGLE
!$OMP END PARALLEL
end do
end
```
And got (the number of threads is the first column):
```
2 1.00000000
2 0.540302277
2 0.857553244
2 0.654289782
1 0.793480337
1 0.701368809
1 0.763959646
1^C
```
However, this implementation looks weird to me:
- the load avg is IMO not a good measure of the CPU occupation. On my system
(macOS with a 4 cores), the load avg is typically between 2 and 3 while the CPU
occupation is constantly around 10% (100% being the 4 cores fully occupied).
See this output from top:
- When an application runs during a long time, it results in a raise of the
load avg, but this is not because some other processes concurrently use the
CPU. And yet the number of threads is dynamically reduced. With such a method,
on average the application will use only half of the cores...
I definitely don't how OMP_DYNAMIC should be implemented, but clearly the
analysis should make a difference between the CPU occupation by the current
application and by the other processes...
