Fortran Performance

Question

Fortran's performance on the Benchmark Game is surprisingly poor. Today, the result puts Fortran 14 and 11 in two quad tests, 7 and 10 in single cores.

Now I know that tests are not perfect, but Fortran was (is there?) Often considered a high-performance computing language, and it seems that the type of problems used in this test should be Fortran's advantage. In a recent article on computational physics, Landau (2008) wrote:

However, [Java] is not as efficient or as well supported for HPC and parallel as FORTRAN and C, the last two have highly developed compilers and many other scientific subroutine libraries available. FORTRAN, in turn, is still the dominant language for HPC, with FORTRAN 90/95 is an amazingly good, modern and effective language; but alas, this is unlikely CS departments and compilers can be expensive.

Is it just because of the compiler used by language interception (Intel free compiler for Linux)?

Answer 1

No, this is not only due to the compiler.

What tests, such as this one, where a program differs from benchmarks, is basically the amount of effort (and quality of effort) that a programmer wrote in writing in any given program. I suspect Fortran is in significant inconvenience in this particular metric - unlike C and C ++, the pool of programmers who would like to try their hand at improving the test program is quite small, and unlike most others, they probably I don’t feel that they have something to prove. Thus, there is no motivation for someone to spend several days looking for the generated assembly code and profiling the program to speed up its work.

This is pretty clear from the results. In general, with sufficient programming efforts and a decent compiler, neither C, C ++, nor Fortran will be much slower than the assembly code - of course, no more than 5-10%, in the worst case, except in pathological cases. The fact that the actual results obtained here are more than an option indicates that “sufficient programming efforts” have not been expended.

There are exceptions when you allow the assembly to use vector instructions, but do not allow C / C ++ / Fortran to use the corresponding built-in compiler functions - automatic vectorization is not even a close approximation of perfection and probably never will. I do not know how much they can be applied here.

Similarly, an exception occurs in things like string processing, where you are heavily dependent on the runtime library (which can be of varying quality; Fortran is rarely the case when a fast string library will make money for the compiler provider!), And basically the definition of "string" and how it is represented in memory.

Answer 2

Some random thoughts:

Fortran used very well because it was easier to identify loop invariants that simplified some optimizations for the compiler. Since

• Compilers have become much more complicated. A huge effort has been put into c and C ++ compilers, in particular. Does fortran contain compilers? I believe gfortran uses the same end of gcc and g ++, but what about the Intel compiler? It used to be good, but anyway?
• Some languages ​​have received many specialized keywords and syntax to help the compiler ( restricted and const int const *p in c and inline in C ++). Not knowing fortran 90 or 95, I can’t say whether they continue.

Answer 3

I looked at these tests. This is not like the compiler is making a mistake or something like that. In most tests, Fortran is comparable to C ++, with the exception of some where it is beaten 10 times. These tests simply reflect what you need to know from the very beginning - that Fortran is simply NOT a comprehensive, interoperable programming language - it is suitable for efficient computation, has good list operations and more, but, for example, IO sucks if you do not do it with using certain Fortran-like methods - for example, 'unformatted' IO.

Let me give you an example - a “backward complement” program that should read a large file (of the order of 10 ^ 8 B) from the stdin line, do something with it, and print the result of a large file to stdout. A rather complicated Fortran program with forcing about 10 times slower on one core (~ 10 s) than optimized with HEAVILY C ++ (~ 1 s). When you try to play with the program, you will see that only simple formatted reads and writes take more than 8 seconds. In the case of Fortran, if you care about efficiency, you simply write the unformatted structure to a file and quickly read it (which is completely not portable and does not work, but no matter who cares, effective code should be fast and optimized for a specific machine, not capable of work everywhere).

So, the short answer is - don’t worry, just do your job - and if you want to write a super-efficient operating system than sorry, Fortran is simply not suitable for this kind of performance.

Answer 4

This figure is stupid.

For example, they measure the CPU time for an entire program to run . As indicated by mcmint (and this may be true) Fortran I / O sucks *. But who cares? In real tasks, one read input for a few seconds than calculations for hours / days / months, and finally, record output in seconds. This is why in most tests, I / O operations are excluded from time measurements (unless, of course, you are testing I / O yourself).

Norber Wiener in his book God and Golem, Inc. wrote

Give man things that are men and a computer, things that are computers.

In my opinion, using this principle when implementing an algorithm in any programming language means:

Write as readable and simple code as you can, and let the compiler do the optimization.

This is especially important in real (huge) applications. Dirty tricks (so heavily used in many tests), even if they can increase the efficiency to some extent (5%, maybe 10%), are not intended for real projects.

/ * C / C ++ uses streaming I / O, but Fortran traditionally uses I / O based entries. Further reading . In any case, the I / O in these tests is so amazing. Using the stdin / stdout redirect can also be the source of the problem. Why not just use the read / write capabilities of the files provided by the language or standard library? Once again, this will be a more real situation.

Answer 5

I would like to say that even if this control point does not bring the best results for FORTRAN, this language will continue to be used for a long time. The reasons for use are not just performance, but also something like simplicity of programmability. Many people who have learned to use it in 60 and 70 are now too old to delve into new things, and they know how to use FORTRAN quite well. I mean, there are many human factors for using a language. The programmer also matters.

Answer 6

Given that they did not publish the exact compiler options that they used for the Intel Fortran compiler, I have little faith in their benchmark.

I would also like to note that both Intel math library, MKL, and AMD math, ACML, use the Intel Fortran compiler.

Edit:

I found compilation options when you click on the name of the quiz. The result is surprising as the level of optimization seems reasonable. This can lead to algorithm performance.