FORTRAN is faster than C++: HTTPS://authors.Elsevier.com/a/1gRnKcPqbl4hv Colin Paul Gloster, Comment on “Gamma-ray spectroscopy using angular distribution of Compton scattering” [Nucl. Instr. and Meth. A 1031 (2022) 166502], 1049:167923, 2023
4 Likes
My opinion about these speed comparisons is that there are several issues involved. First is the underlying algorithm. Is it the same algorithm that has been implemented that is being compared? If there are two different algorithms, then comparisons between the languages with which they have been implemented is largely irrelevant.
The second is the underlying hardware. Even if the two codes are run on the same machine, they might be using the underlying hardware differently. Does one code use gpus and the other doesn’t? These days compilers have the ability to compile fortran and c++ code and offload it to gpu hardware. If one language is doing that and the other isn’t, then the language itself is mostly irrelevant. In the past, other issues involve using or not using extended floating point registers, or choosing differently between static, stack, and heap allocation of temporary arrays, and so on. These have relatively little to do with the language specifications, but rather on implementation details of how the language translates source code. That is an important feature of the language, but apart from perhaps the use of compiler options to modify the behavior, there is little that either the language designers or the programmer using the language can control.
So the important part of this issue is whether it allows the programmer to efficiently map the best algorithm and to make optimal use of whatever is the underlying hardware. To give some specific examples, when fortran did only static allocation of everything, that gave it some efficiency advantages over other languages that were stack/heap based because the management of the stack and heap requires overhead. But that choice also limited fortran in the types of problems that it could easily address because it could more easily exhaust the available static memory. That is why fortran has now evolved into a stack/heap language. Particularly since the recursive attribute is now the default for subprograms (implemented with stack/heap allocation of local variables), this represents a major change from f77 and earlier.
Another issue is pointers. Before pointers were available in the fortran, there were some algorithms, particularly those involving data structures (linked lists, trees, directed graphs, etc.), that were difficult to implement. Pointer based algorithms could sometimes be implemented using array indexing, but it is not really the same power and flexibility as actual pointers in the language. That limitation was mostly solved with f90 and with the later refinements to pointer and allocatable entities.
Another issue was the difference in aliasing rules in c/c++ and fortran. By default, fortran does not allow arguments to be aliased, while c/c++ does. That means that to produce efficient code, the c++ compiler must check for aliasing at run time, and then either assume the worst case, or branch to the appropriate code section as necessary. Fortran now has the target attribute, which tells the compiler that aliases might occur, so that makes fortran act more like c/c++. Also, I think c/c++ now has the ability to designate when an entity is not aliased, allowing the compiler to make the same kind of optimization assumptions as fortran. Thus while this issue is still present, I think it is not as important as it was 30+ years ago.
Finally, another issue is how much of a program is implemented at compile time rather than run time. In many comparisons of languages and codes, the compile time is not included, only the run time. So if one compiler happens to do more work at compile time, it shows an advantage at run time. If a program is compiled and executed only once, then you might argue that the comparison is unfair, that some combination of both times is appropriate. But if a code is compiled once, and then executed millions of times, then that compilation choice becomes a real and practical diffrerence between the languages. This is another one of those features that the programmer and the language designers may have little control over, it is in the compiler writer’s domain.
7 Likes
Dear all:
A GPU implementation is faster than a CPU implementation.
CPU implementations in FORTRAN are faster than a CPU implementation in C++.
Yours faithfully,
Colin Paul Gloster
1 Like
These are monte carlo simulations, so another important factor in speed is the pseudorandom number generator. In general, library calls might differ between the languages, so sometimes comparisons between languages reduce down to simply comparisons between the library calls. Library routines make differ choices between speed, accuracy, and robustness. For PRNG routines in particular, there are fast ones that are not very good and there are slow ones that are very good and many choices in between.
1 Like
this used to be true but is much less true on modern hardware. AES gives perfect randomness with very high throughout (roughly 8 cycles per 64 bit integer of randomness) and if you don’t need security Xoshiro and friends give very serviceable random numbers even faster. if your random number generation is slow (or you’re using a LCG and running into quality issues), you’re probably doing something wrong.
1 Like