public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dewhurst@mpi-halle.mpg.de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgomp/108494] New: Slow thread creation with nested loops in GFortran Date: Mon, 23 Jan 2023 11:37:07 +0000 [thread overview] Message-ID: <bug-108494-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108494 Bug ID: 108494 Summary: Slow thread creation with nested loops in GFortran Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: dewhurst@mpi-halle.mpg.de CC: jakub at gcc dot gnu.org Target Milestone: --- This is an issue with very slow thread creation for nested loops in code compiled with GFortran, however I suspect it may be due to the libgomp library. Here is a simple example the problem: program test implicit none integer l !$OMP PARALLEL DO & !$OMP NUM_THREADS(1) do l=1,1000 call foo end do !$OMP END PARALLEL DO end program subroutine foo implicit none integer, parameter :: l=200,m=100,n=10 ! number of threads integer, parameter :: nthd=10 integer i,j ! automatic arrays real(8) a(n,l),b(n,m),x(m) a(:,:)=2.d0 b(:,:)=3.d0 do i=1,l !$OMP PARALLEL DO DEFAULT(SHARED) & !$OMP NUM_THREADS(nthd) do j=1,m x(j)=dot_product(a(:,i),b(:,j)) end do !$OMP END PARALLEL DO end do end subroutine The wall-clock time is about 0.5 seconds when compiled with Intel or PGI Fortran. However, for GFortran compiled with gfortran -O3 -fopenmp test.f90 and OMP_NESTED set to true, the wall-clock time is about 70 seconds, or about 140 times slower. (The ‘dot_product’ can be removed from the loop – all the time is taken with thread creation). This only affects nested loops; if the OMP directives are removed from the loop in the program part in the code above then GFortran is as fast as the other compilers. I’ve tried several different versions of GFortran (from 7.5.0 to 12.1.0) on different Linux machines and it’s slow on all of them. It may problem with libgomp. If I substitute the libgomp library for that provided with the NVIDIA compiler (on our machine this is in the directory nvhpcsdk/22.11/Linux_x86_64/22.11/compilers/lib/libgomp.so.1) then it’s as fast as the others. This has been reproduced by others and also in Windows, see here: https://fortran-lang.discourse.group/t/slow-thread-creation-with-nested-loops-in-gfortran/5062
next reply other threads:[~2023-01-23 11:37 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-23 11:37 dewhurst@mpi-halle.mpg.de [this message] 2023-01-23 13:08 ` [Bug libgomp/108494] " rguenth at gcc dot gnu.org 2023-01-23 14:53 ` amonakov at gcc dot gnu.org 2023-01-23 14:59 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-108494-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).