public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "prop_design at protonmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler Date: Sat, 27 Jun 2020 23:34:18 +0000 [thread overview] Message-ID: <bug-53957-4-kXjT04zHhg@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-53957-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 prop_design at protonmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |prop_design at protonmail dot com --- Comment #19 from prop_design at protonmail dot com --- hi everyone, I'm not sure if this is the right place to ask this or not, but it relates to the topic. I can't find the other thread about graphite auto-parallelization that I made a long time ago. I tried gfortran 10.1.0 via MSYS2. It seems to work very well on the latest version of PROP_DESIGN. MP_PROP_DESIGN had some extra loops for benchmarking. I found it made it harder for the optimizer so I deleted that code and just use the 'real' version of the code it was based on called PROP_DESIGN_MAPS. So that's the actual propeller design code with no additional looping for benchmarking purposes. I've found no Fortran compiler and do the auto-parallelization the way I would like. The only code that would implement any at run time actually slowed the code way down instead of sped it up. I still have my original problem with gfortran. That is, at runtime no actual parallelization occurs. The code runs the exact same as if the commands are not present. Oddly though, the code does say it auto-parallelized many loops. Although, not the loops that would really help, but at least it shows it's doing something. That's an improvement from when I started these threads. The problem is if I compile with the following: gfortran PROP_DESIGN_MAPS.f -o PROP_DESIGN_MAPS.exe -O3 -ffixed-form -static -march=x86-64 -mtune=generic -mfpmath=sse -mieee-fp -pthread -ftree-parallelize-loops=2 -floop-parallelize-all -fopt-info-loop It runs the exact same way as if I compile with: gfortran PROP_DESIGN_MAPS.f -o PROP_DESIGN_MAPS.exe -O3 -ffixed-form -static -march=x86-64 -mtune=generic -mfpmath=sse -mieee-fp Again, gfortran does say it auto-parallelize some loops. So it's very odd. I have searched the net and can't find anything that has helped. I'm wondering if for Linux users, the code actually will work in parallel. That would at least narrow the problem down some. I'm using Windows 10 and the code will only run with one core. Compiling both ways it shows 2 threads used for awhile and then drops to 1 thread. The good news from when this was posted is that gfortran ran the code at the same speed as the PGI Community Edition Compiler. Since they just stopped developing that, I switched back to gfortran. I no longer have Intel Fortran to test. That was the compiler that actually did run the code in parallel, but it ran twice as slow instead of twice as fast. That was a year or two ago. I don't know if it's any better now. I'm wondering if there is some sort of issue with -pthread not being able to call anything more than one core on Windows 10. You can download PROP_DESIGN at https://propdesign.jimdofree.com Inside the download are all the *.f files. I also have c.bat files in there with the compiler options I used. The auto-parallelization commands are not present, since they don't seem to be working still. At least on Windows 10. The code now runs much faster than it used to, due to many bug fixes and improvements I've made over the years. However, you can get it to run really slow for testing purposes. In the settings file for the program change the defaults like this: 1 ALLOW VORTEX INTERACTIONS (1) FOR YES (2) FOR NO (INTEGER, NON-DIM, DEFAULT = 2) 2 ALLOW BLADE-TO-BLADE INTERACTIONS (1) FOR YES (2) FOR NO (INTEGER, NON-DIM, DEFAULT = 2) or like this 1 ALLOW VORTEX INTERACTIONS (1) FOR YES (2) FOR NO (INTEGER, NON-DIM, DEFAULT = 2) 1 ALLOW BLADE-TO-BLADE INTERACTIONS (1) FOR YES (2) FOR NO (INTEGER, NON-DIM, DEFAULT = 2) The first runs very slow, the second incredibly slow. I just close the command window once I've seen if the code is running in parallel or not. With the defaults set at 2 for each of those values the code runs so fast you can't really get a sense of what's going on. Thanks for any help, Anthony
next prev parent reply other threads:[~2020-06-27 23:34 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-13 20:00 [Bug middle-end/53957] New: " burnus at gcc dot gnu.org 2012-07-18 11:26 ` [Bug middle-end/53957] " rguenth at gcc dot gnu.org 2012-07-18 12:02 ` rguenth at gcc dot gnu.org 2012-07-18 12:09 ` [Bug fortran/53957] " rguenth at gcc dot gnu.org 2012-07-18 12:46 ` burnus at gcc dot gnu.org 2012-07-18 13:18 ` rguenther at suse dot de 2012-07-18 14:05 ` burnus at gcc dot gnu.org 2012-07-18 14:48 ` rguenth at gcc dot gnu.org 2012-07-26 9:59 ` burnus at gcc dot gnu.org 2012-07-26 10:19 ` rguenth at gcc dot gnu.org 2012-09-11 15:02 ` rguenth at gcc dot gnu.org 2013-01-16 22:53 ` burnus at gcc dot gnu.org 2013-06-10 4:41 ` prop_design at yahoo dot com 2013-06-10 17:44 ` prop_design at yahoo dot com 2013-06-22 13:04 ` dominiq at lps dot ens.fr 2013-06-23 5:25 ` prop_design at yahoo dot com 2020-06-27 23:34 ` prop_design at protonmail dot com [this message] 2020-06-28 10:49 ` tkoenig at gcc dot gnu.org 2020-06-28 11:03 ` tkoenig at gcc dot gnu.org 2020-06-28 15:40 ` prop_design at protonmail dot com 2020-06-29 9:36 ` rguenther at suse dot de 2020-06-29 14:09 ` prop_design at protonmail dot com 2020-07-29 22:25 ` prop_design at protonmail dot com
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-53957-4-kXjT04zHhg@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).