Which is the best Fortran compiler? We’re often asked that question, but there is no single answer. All compilers have strong and weak points, and your choice should depend on finding the best match between your requirements and a compiler’s strengths.
To help customers make an informed decision, former Polyhedron Software Ltd. and then Polyhedron Solutions Ltd. had compiled a series of charts comparing the main contenders. The charts cover the questions we are most frequently asked, but avoid subjective issues, such as stability, quality of support and documentation etc. Please contact us if you need further advice in coming to your decision.
In 2019 we took over the running of the benchmark tests with the most recent versions of Fortran compilers being available (a big Thank You to Dr. John Appleyard of Polyhedron Solutions Ltd. who passed the test suite and his administration programs and scripts on to us).
A Few Advanced Notes
Here we only compare the run-times of computing intensive Fortran programs created by various Fortran compiler systems – the so-called runtime benchmarks. As stated in our webpage “Fortran Compiler Advice”, it should be emphasized that run-time performance is not the only criterion for choosing a Fortran compiler. What is the use of the best performance when the compiler is difficult to use – the computational results may not be accurate or accurate enough; the compilation and link times are frustratingly long; the error diagnostics are weak and so on?
The compiler comparisons by Dr. Appleyard are much more detailed than the ones presented here. In particular, the diagnostic capabilities and the respective Fortran language scope (Fortran 95, 2003, 2008, etc.) should be noted. Regarding the latter, the tables of Ian Chivers & Jane Sleightholme are also informative.
Desirable (and actually necessary) would be the review of the computational results and the numerical accuracy of the Fortran compiler systems. In particular, the messages of some compilers due to numerical problems – see, for example, the results of “capaci (ta)” and “channe (l2)” – raise doubts about the correctness of the test programs. Maybe one day we will find the time for more thorough analysis in addition to our regular daily business. We ask for your patience and understanding.
Testing Equipment and Conditions
The test environment is a standard PC equipped with an Intel® Core ™ i7-9700F CPU @ 3.00GHz (8 cores) and 16GB of RAM. On this both Microsoft Windows 10 and Linux Mint 19.2 are installed.
The tested Fortran programs are in source code on the website of Polyhedron Solutions Ltd.. Below are our results of the run-time benchmarks. The 64-bit compiler variants were used, with the exception of the Lahey Fortran LF compiler (formerly LF95), which exists only as a 32-bit compiler and is also listed here because of its wide distribution.
Compiling was done with compiler and linker options as listed below (almost all compiler systems act as “drivers”, so start the compiler first and then call the linker).
Throughout, the optimizers of the compiler systems were used to get the “highest optimization level” (according to the compiler’s documentation) and – if supported – processor-specific options were set, so that the binary code for the existing CPU was optimized. Furthermore, if not specified by the optimization level, loop unrolling was used.
AP stands for AutoParallel, i.e. the compiler system also tries to parallelize the code automatically.
The benchmark programs were run several times, at least 10 times in a row, and the respective run-time was measured. If the run-time measurements stabilized (i.e., was less than 1% deviation from the previous measurement), the benchmark for the affected program was completed.
Run-times were measured in seconds.
Green cells: the run-time is in the range of 10% of the shortest run-time .
Red cells: the run-time is more than 150% of the shortest run-time .
The names of the benchmark programs are truncated to 6 characters.
|Fortran Compiler System||Compiler- and Linkeroptions, Windows|
|Absoft ProFortran 19.0||-m64 -O4 -speed_math=11 -march=wolfdale -xINTEGER -stack:0x80000000|
|Absoft ProFortran 19.0 (AP)||-m64 -O5 -apo -speed_math=11 -march=wolfdale -xINTEGER -stack:0x80000000|
|Silverfrost FTN95 8.51||/64 /optimise, /stack:0x10000000|
|gfortran 8.1||-O3 -funroll-loops -ffast-math -o|
|Lahey GNU 6.4||-O3 -funroll-loops -ffast-math -o|
|Lahey LF (LF95), 32-Bit||-inline (35) -o1 -sse2 -nstchk -tp4 -ntrace -unroll (6) -zfm|
|Intel Visual Fortran, 2019 Update 5||/fast /link /stack:64000000|
|Intel Visual Fortran, 2019 Update 5 (AP)||/fast /Qparallel /link /stack:64000000|
|NAG Fortran 6.2||-abi=64 -O4 -Ounroll=4 -s -v -V|
|PGI Fortran 19.4||-V -fastsse -Munroll=n:4 -Mipa=fast,inline|
|PGI Fortran 19.4 (AP)||-V -fastsse -Munroll=n:4 -Mipa=fast,inline -Mconcur=innermost,allcores|
|Windows – Runtime Benchmarks 64-Bit Fortran|
During some program runs, exceptions (eg value overflows, value underflows, etc.) were reported that indicate numerical problems. The program reports during or at the end of the program run:
1) “The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG”.
2) “The following floating-point exceptions are signalling: IEEE_INVALID_FLAG”.
3) “Warning: Floating underflow occurred”.
4) “Warning: ieee_underflow is signaling. FORTRAN STOP”.
5) “Warning: ieee_inexact is signaling. FORTRAN STOP”.
|Fortran Compiler System||Compiler- and Linkeroptions, Linux|
|Absoft ProFortran 19.0||-m64 -Ofast -h4 -speed_math=10 -march=wolfdale -xINTEGER -fPIC -o|
|Absoft ProFortran 19.0 (AP)||-m64 -apo -O5 -h4 -speed_math=10 -march=wolfdale -xINTEGER -no-pie -o|
|gfortran 7.4||-march='native' -funroll-loops -O3 -o|
|Intel Visual Fortran, 2019 Update 5||-Ofast -fast -ipo -o|
|Intel Visual Fortran, 2019 Update 5 (AP)||-Ofast -fast -ipo -parallel -o|
|NAG Fortran 6.2||-o -abi=64t -O4 -Ounroll=4 -s -v -V|
|PGI Fortran 19.4||-V -O4 -fastsse -Munroll=n:4 -m64 -o|
|PGI Fortran 19.4 (AP)||-V -O4 -fastsse -Munroll=n:4 -m64 -Mconcur=allcores -ta=multicore -o|
|Linux – Runtime Benchmarks 64-Bit Fortran|
6) “AERMOD Finishes UN-successfully”
7) “The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG, IEEE_DENORMAL”
8) “forrtl: severe (174): SIGSEGV, segmentation fault occurred”