I need to use some Fortran code that was developed by a co-worker using Microsoft Visual Studio (it is a modified version of this groundwater flow model). However, I don't have an ifort license, and generally prefer to use open-source alternatives, so I am trying to transition to gfortran. After much googling and time on StackOverflow, I've successfully created a makefile, compiled the code, and run a simulation using gfortran. However, while benchmarking I found that the code I compiled with gfortran runs ~2.5x slower than my coworker's code compiled from Visual Studio (~30 seconds compared to ~13 seconds). Also, the size of the resulting .exe file from gfortran is about half that of Visual Studio.
I understand that there can be some differences in speed just due to switching compilers; however, the difference I observe seems extreme, leading me to believe there are certain compiler settings that differ between the two. I realize that the question, 'how can I optimize my Fortran code?' is vague and has been answered in detail elsewhere. Instead, my question is: What's the most efficient way to duplicate or approximate a compilation carried out using Microsoft Visual Studio (+ ifort) with gfortran?
My first instinct was to have my co-worker export a makefile from Microsoft Visual Studio (as described here), which I could then modify to work with gfortran by using equivalent settings where possible; however, it appears to be no longer possible to export a makefile from within Visual Studio. Second, I looked for a Fortran equivalent to MakeItSo, but didn't have any luck. I also had my co-worker send me screenshots of the Configuration Properties for Fortran in Visual Studio; however, there appear to be Visual Studio settings for which I cannot find clear analogs in gfortran (for example, the "Favor Size or Speed?" switch) seen here:
FWIW, I am running gfortran on Cygwin:
$ gfortran --version
GNU Fortran (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
After help in the comments section from #VladimirF, I have updated my makefile and can confirm that flags are being successfully passed to gfortran:
$ make SUTRA
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o slake_mods.o slake_mods.F
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o fmods_3_0.o fmods_3_0.F
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o slake.o slake.F
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o slake_blas.o slake_blas.F
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o slake_linpack.o slake_linpack.F
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o slake_slatec.o slake_slatec.F
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o ssubs_3_0.o ssubs_3_0.F
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o usubs_3_0_non-Jeff.o usubs_3_0_non-Jeff.F
gfortran -O3 -march=native -ffixed-line-length-72 -m64 -c -o sutra_3_0.o sutra_3_0.F
gfortran slake_mods.o fmods_3_0.o slake.o slake_blas.o slake_linpack.o slake_slatec.o ssubs_3_0.o usubs_3_0_non-Jeff.o sutra_3_0.o -m64 \
-O3 -march=native -ffixed-line-length-72 -m64 -o SUTRA
My co-worker is using Intel Visual Fortran Compiler XE 12.0.2.154 on IA-32 with Microsoft Visual Studio 2008.
Related
I noticed that in the default release configuration, qmake (qmake 3.1, qt 5.9.5 - whatever is installed on my Ubuntu build box) passes -Wl,O1 to g++ when linking. So the linking command line looks like
g++ -Wl,-O1 -flto -O2 -o program program.o lib1.a lib2.a ...
where -flto -O2 are the options that I'm passing via QMAKE_LFLAGS_RELEASE to enable LTO.
Now the question: why qmake has this -Wl,-O1 option and is it going to interfere with LTO?
QMake passes -Wl,O1, because it is meant to be a good default.
It will not harm LTO, because your -O2 option comes later and overrides the -Wl,O1.
From g++'s man page:
If you use multiple -O options, with or without level numbers, the
last such option is the one that is effective.
You can remove the -Wl,-O1 from your Makefile by specifying
QMAKE_LFLAGS_RELEASE -= -Wl,-O1
NOTE: I do not understand object files, linking, or make files very well. I only understand enough to get a program running
I'm working on a GPU accelerated version of a previous project of mine that works with no problems. I currently am testing a modified version of a make file I have used for other CUDA programs.
The file:
exe: main.o b.o
gcc -fopenmp -L /usr/local/cuda/lib64 -o exe main.o b.o -lcudart -lglfw -lGL
main:
gcc -fopenmp -o main.o main.c -Ofast -march=native -mtune=native -lglfw -lGL -I /usr/local/cuda/include
b.o: b.cu b.h
nvcc -Xcompiler -fPIC -ccbin clang-3.8 -c -o b.o b.cu
b.cu is a CUDA file containing some test functions; it does not effect anything yet.
When I run the compiled program, it only uses a single core, and runs at 1/4 the frame rate (this is what would be expected on a 4 core cpu).
I've Googled as many questions as I can, but I have not found any results that work for me.
System info:
OS: Ubuntu 18.04 bionic
CPU: AMD A8-3850
GPU: GeForce GTX 1060 6GB
RAM: 7974MiB
GCC: 7.3.0
I am currently compiling spec2000 art benchmark using following 2 flag settings:
-Ofast -m32 -march=native
-Ofast -m32 -march=native -fno-tree-vectorize
The second setting just disable the vectorizer. However, when I checked the objdump of the 2 settings, both of them shows some packed instructions like vmovapd, vxorpd, etc.
Can anyone provide some explanations? Thanks.
I'm using GCC 4.7.2 and LD 2.23 but when I add -flto to my compile options my compile time increases by over 20%! The manual seems to indicate that -fuse-linker-plugin is needed for the optimization to work. It also says that it's enabled by default with -flto but when I add it explicitly I see the following error in the link command:
g++: error: -fuse-linker-plugin is not supported in this configuration
According to manual, it should be supported by LD 2.21 or greater. Any idea why I'm getting this error? For reference here are examples of my full compile commands:
g++ -Wall -pipe -O3 -flto -fno-strict-aliasing -mtune=generic --no-exceptions -fPIC -c some.cc
g++ -o exec -Xlinker some1.o some2.o -static some1.a some2.a -Wl,--wrap,open -flto -fuse-linker-plugin
Running 'ld --help | grep plugin' shows "-plugin" option so I don't understand why GCC is complaining:
-plugin PLUGIN Load named plugin
-plugin-opt ARG Send arg to last-loaded plugin
Link time optimizations aren't supposed to reduce compilation time, but optimize runtime of your program.
#options, just add "-flto -fuse-linker-plugin" to your CFLAGS(or CXXFLAGS for c++) and LDFLAGS and it should work just fine.
#gold: ld --version is probably gonna return gnu LD, to switch to gold, make ld symlink which ld point to which ld.gold
e.g. ln -s /usr/bin/ld.gold /usr/bin/ld
I have a pthreads program. I have to compile it with gcc -pthread in Linux (-pthreads is unrecognized option) and gcc -pthreads in Sun (-pthread is unrecognized option). Why the difference, since it's the same compiler? However, -lpthread works on both, but I heard this isn't always sufficient.
The Solaris -pthreads and Linux -pthread options do equivalent things. Apparently, gcc-4.x series accepts -pthread for Solaris as well.
You do want the -pthread/-pthreads option while compiling because it adds multithreading support in the preprocessor and the linker.