g95 -march switch not working

[SmeeBobFred]

Hi,

I've been trying to optimise some FORTRAN code and I've managed to make it about 4 times quicker (largely due to the -O3 switch in g95). I've been trying to use the -march switch to possibly optimise further but nothing I set it equal to is recognised. This is my basic compile command:

g95 -o "test.exe" "master.f95" "parameters.f95" -O3 -ftree-vectorize -funroll-loops

I've tried adding all of these (I have a Core i7-920):

-march=native
-march=corei7
-march=core2
-march=x86-64

but ALL of them give me the following error (with "native" replaced with whatever I've specified):

error: bad value (native) for -march= switch
error: bad value (native) for -mtune= switch

The only one I've found that DOES work is -march=i386 but presumably this is the default value since it changes nothing.


Does anyone have any idea why this doesn't work? I've tried using both the "stable" and "snapshot" versions of g95 (MinGW), both are the same.

 

[mikrom]

I tried to compile the last source I posted here with g95 and same options as you - and I got the same error:

$ g95 -O3 -ftree-vectorize -funroll-loops -march=native complex_function.f95 -o complex_function
complex_function.f95:0: error: bad value (native) for -march= switch
complex_function.f95:0: error: bad value (native) for -mtune= switch

The I tried the same options with gfortran and it compiles fine

$ gfortran -O3 -ftree-vectorize -funroll-loops -march=native complex_function.f95 -o complex_function

I don't know why this doesn't work with g95 when it works with gfortran - maybe a bug in g95, but I suggest you to use gfortran.
When you have the recent version of MinGW, then gfortran is probably included.

I have an older MinGW version with g77 and these versions of g95 and gfortran (installed additionally):

$ g95 --version
G95 (GCC 4.0.4 (g95 0.92!) Oct 14 2008)
Copyright (C) 2002-2005 Free Software Foundation, Inc.

G95 comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of G95
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

$ gfortran --version
GNU Fortran (GCC) 4.4.0 20080603 (experimental) [trunk revision 136333]
Copyright (C) 2008 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

 

[SmeeBobFred]

The snapshot I currently have installed has "G95 (GCC 4.1.2 (g95 0.93!) Jun 16 2010)" but it has not installed gfortran with it. I tried to find gfortran by itself but couldn't - there doesn't seem to be any Windows builds available on the official releases site.

Instead I just downloaded the main MinGW installer and chose to install the FORTRAN compiler. I have another problem now though - the MinGW installer didn't register the install path (unlike the g95 installer) so I have to type in "C:\Program Files (x86)\MinGW\bin\gfortran" whenever I want to run it. Then, when I try to compile something, it fails with this error:

The program can't start because libgmp-10.dll is missing from your computer.

This file is in the gfortran directory as it should be, so I'm assuming this is also because the path isn't registered.

Do you know how I can register the path so it'll work in the command window?

 

[mikrom]

try o add teh path
C:\Program Files (x86)\MinGW\bin\gfortran
to the PATH variable

 

[SmeeBobFred]

That didn't work but adding C:\Program Files (x86)\MinGW\bin to my PATH variable lets me run it from the command prompt. However, it doesn't work when run from a batch file ("gfortran isn't a recognised command"), which I need. In fact, g95 isn't even working through a batch file now.

Even if I run gfortran straight from the command prompt, I now get this error:

"Fatal Error: Can't open module file 'parameters.mod' for reading at (1): No such file or directory"

When running g95, it creates .mod files for each module in "parameters.f95" automatically but apparently gfortran doesn't. Is there another step I'm missing?

 

[mikrom]

Looking at your path "C:\Program Files (x86)", I guess you have Windows 7. I have MinGW installed only on Windows XP and Windows Vista. Maybe MinGW has a problem with Windows 7 ?..

But look at the page page

http://gcc.gnu.org/wiki/GFortranBinaries

There is a standalone installer available:

http://users.humboldt.edu/finneyb/gfortran-windows-20110419.exe

Uninstall MinGW and try to install gfortran using the standalone installer.

 

[SmeeBobFred]

Thanks for the link. I ran the installer but it seems to be stuck on this step:

Extract: README.html
Output folder: C:\Program Files (x86)\gfortran

All the buttons are greyed out and I can't do anything except to End Task. It's been stuck there for 2 minutes so far...

 

[mikrom]

It's strange why it doesn't work.
Have you installed with "Run as Administrator" ?

 

[SmeeBobFred]

The installer did finish eventually, not sure why it hanged at that point.

Didn't help though, the PATH still isn't registered and if I do it manually, it still isn't recognised in a batch file.

 

[mikrom]

Hi SmeeBobFred,

Now I installed gfortran on my computer with Windows 7 Enterprise 64-bit, Service Pack 1

I downloaded the gfortran installer and it installed fine without any problems into the default location
c:\Program Files (x86)\gfortran

Now, it runs and works at Command Prompt:

c:\_mikrom\Work\gfortran_test>gfortran
gfortran: fatal error: no input files
compilation terminated.

c:\_mikrom\Work\gfortran_test>gfortran --version
GNU Fortran (GCC) 4.7.0 20110419 (experimental) [trunk revision 170140]
Copyright (C) 2011 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


c:\_mikrom\Work\gfortran_test>gfortran -O3 -ftree-vectorize -funroll-loops -march=native complex_function.f95 -o complex_function

c:\_mikrom\Work\gfortran_test>complex_function
Arccos(-1.000 + J* 0.000) = 3.14159274 + J*-.00000000
Arccos(-0.500 + J* 0.000) = 2.09439516 + J*0.00000001
Arccos( 0.000 + J* 0.000) = 1.57079637 + J*-.00000000
Arccos( 0.500 + J* 0.000) = 1.04719758 + J*0.00000001
Arccos( 1.000 + J* 0.000) = -.00000000 + J*-.00000000
Arccos( 0.000 + J*-1.000) = 1.57079637 + J*0.88137364
Arccos( 0.707 + J* 0.707) = 0.99893749 + J*-.76428545
Arccos( 0.866 + J* 0.500) = 0.78539819 + J*-.65847898
Arccos( 0.000 + J* 1.000) = 1.57079637 + J*-.88137364

IMHO, when it doesn't work for you, it must be something wrong with your computer.

 

[SmeeBobFred]

Turned out all I needed to do to get gfortran to work in a batch file was restart the computer (couldn't do it before as I was waiting for other calculations to finish).

I've used gfortran with the same settings as I've used with g95 (-O3 -ftree-vectorize -funroll-loops) and these are the results:

g95: 19.7 mins
gfortran: 38.8 mins
gfortran (march=native): 40.2 mins
gfortran (march=corei7): 40.1 mins

So it seems that g95 is a lot quicker than gfortran to begin with so the march switch doesn't help me. Unless there's another way to optimise gfortran, I guess my current g95 setup is the fastest I'll be able to get my code running?

 

[FJacq]

I only use the option -O3 with both g95 and gfortran.

It is very unusual to observe a code running faster when compiled with g95. I like g95 for the debug phase but I always switch to gfortran (or still better : Intel ifort) when building up the fast version.

Notice also that gfortran like ifort enable to use // processing with OpenMP (multi threading). On the opposite, g95 comes with an implementation of F2008 corrays.

http://www.polyhedron.com/pb05-win32-f90bench_SBhtml

François Jacq

 

[SmeeBobFred]

Thanks for the info. I tried splitting some matrix manipulation using the OpenMP and, although it seems to be splitting into worker threads correctly, it ends up being slower than the single-threaded version. I guess the time saved by splitting the manipulation into multiple threads doesn't outweigh the overhead introduced.

 

[NickFort]

For some reason, I've found that executables compiled with the MinGW gfortran binaries are literally hundreds of times slower on 64-bit than on 32-bit (

http://www.tek-tips.com/viewthread.cfm?qid=1644242&page=3).

I couldn't even get the gfortran binary you mentioned working on 64-bit; it kept spitting out some error.

Is there any way you could try compiling and executing on a 32-bit system? Might help...

I also echo the above sentiments about G95 vs gfortran; I use it occasionally during debugging, but I find it much slower than gfortran, and it's not nearly as well-maintained.

--------------------------------------
Background: Chemical engineer, familiar mostly with MATLAB, but now branching out into real programming.

 

[mikrom]

IMHO, the gfortran installer on the link above contains 32-bit compiler, therefore it installs by default into Program Files (x86) directory.

 

[SmeeBobFred]

Yeah I'm pretty sure the versions of both g95 and gfortran I have are 32-bit but g95 comes out faster every time.

I've tried two different multi-threaded sections with gfortran so far, both slow the program down. I've yet to try co-arrays with g95 and I've also got a trial version of ifort to try also.

 

[mikrom]

Both g95 and gfortran are free - so you can install both. IMHO, for some things g95 is better, for other gfotran. So, if your actual code compiled with g95 runs faster, then use g95 now... maybe for other purpose gfortran will be better...
I have installed on one computer all 3 free compilers: g77 (which is now obsolete), gfortran and g95 - I'm primarily using g95 (for purpose of this forum).

 

[SmeeBobFred]

I've discovered that the reason for the slowness of my program in gfortran was due to heavy I/O. I've now removed an unneeded portion of code that was writing to a file hundreds of thousands of times and the speeds of g95 and gfortran are now very similar (g95 is still faster though).

I've also had the opportunity to try Intel's "Visual Fortran" 2011. I like the integration with Visual Studio 2010 and I've managed to get it faster than both g95 and gfortran by playing with certain optimisations. I currently use these switches to get it ~15% faster than g95:

/nologo /O3 /Qparallel /assume:buffered_io /Qip /arch:SSE3 /fp:strict /module:"Release\\" /object:"Release\\" /Fd"Release\vc100.pdb" /libs:static /threads /c

The "/Qparallel" switch does help but the second core is seldom used - average CPU usage is ~14% (12.5% = maxing out one core). I've tried using OpenMP again in two parts of the code (with Qparallel both enabled and disabled) but once again, it just slows the program down. These switches which in theory should take advantage of SSE instructions also slow the code down, strangely:

/QaxSSE4.2 /QxSSE4.2

I think the only thing left to try is to create an x86-64 executable. I don't know how though - I'm sure I've seen an option for it somewhere but I can't find it now. I installed the version of Intel Visual Fortran that supports both "ia32" and "x86-64". Anyone know how to do this?

 

[SmeeBobFred]

Never mind, I figured it out. I had to add my own "Platform" for x64 (I'm used to it being there automatically) in the Configuration Manager. I had to find and add some more library directories to get it to compile but it does work now. The x64 version of the program is a bit quicker and, for some reason, does actually take advantage of SSE4.2 now for an extra speed boost. Here's my program's speed after all of these coding and compiling tweaks:

Unoptimised g95: 678.3 s
Optimised g95: 83.2 s
Optimised gfortran: 100.6 s
Optimised ifort: 72.8 s
Optimised ifort x64: 62.9 s