Which Compiler is faster when dealing with large matrices and arrays? Intel Fortran or C++?

[george_M_]

According to different discussions found in the net, on which is the optimum programming language in handling large matrices and arrays (use the latest compilers for each language) there is a general  disagreement  on whether Fortran performs better than C++ or vise versa. Related to the general abilities of C++, especially when it is used for graphical applications, there is no doubt that C++ is an excellent tool. If you are about to develop a Finite Element Analysis Solver that will handle a large number of calculations performed through the use of matrices and arrays then is C++ going to perform similarly with Fortran or is Fortran still the best way to go in terms of computational performance?

My understanding is that C++ improved significantly in this area but still Fortran is more efficient and robust when it comes to this issue, even though if a C++ programmer is expert in tweaking he/she can reach C++ performance to the Fortran levels.

Any feedback on this issue from those that have relevant experience and especially from those that are involved in the development of the two compilers (Intel (R) Fortran / C++)?

Regards,

George

[TimP]

For work on large matrices, you would likely use a library (e.g. Intel MKL), so that performance doesn't depend on which programming language you are calling from.  Then, it's largely a matter of convenience, with Fortran offering more relevant built-in language features, while calling a library from C++ with Fortran-compatible interface is not pretty.  For example, the most widely used Fortran compilers offer options to implement the MATMUL intrinsic as a call to the optimized library.

Array assignment notation is a likely convenience feature built into Fortran.  Intel has added the similar Cilk(tm) Plus extended array notation feature to their compiler, and an effort is continuing to implement it in gcc, but that, and libraries such as Boost, aren't strictly part of C++.

The most popular C++ compilers (except Microsoft) have added the __restrict qualifier extension (same functionality as C99 restrict) to facilitate optimization, and are adding the OpenMP 4 parallel simd pragmas.   C++ compilers disagree on the syntax required to optimize in certain situations, such as std::max() which is excellent in Intel C++ but has to be changed for optimization in g++ or MSVC++.  It's usually possible to achieve full performance in either Fortran or C++ (by testing C vs. C++ alternatives for the compiler of choice), but there's more effort involved in C++.

Microsoft C++ is the only C++ compiler considered by many Windows developers; it has a much more limited selection of auto-vectorizations, supports an old version of OpenMP standard, and supports very little of C99.  So you will need to choose another C++ (Intel or latest g++) if you want one which competes with Fortran.

[george_M_]

Thank you Tim for your response. I am more interested in cases where the code does not use libraries thus optimization comes from the compiler in combination with the code developed from the programmer.

[jimdempseyatthecove · Accepted solution]

If your application is manipulating large matrices using relatively standard functions, then the best route is to find a well written library such as MKL or BLAS. And in which case it will not matter as to what language you use. Assuming you can organize the data the same.

However, many simulation programs, which fall into a class of Finite Element Solvers, have requirements that fall outside the realm of functionality best served by a library such as MKL or BLAS. IOW you have a different set of requirements.

For both languages (Fortran and C++), the performance will come from four areas in order of importance:

1) Your ability to perform data layout that is favorable to vectorization
2) The compiler ability to optimize the code to maximally incorporate vectorization
3) Language features to permit you to express the problem efficiently
4) Language features to permit effective parallelization

Both languages can produce the same efficiency as well as inefficiencies depending on the abilities of the programmer. The programming emphasis for the C++ programmer is to make collections of objects. This tends to organize data as Array of Structures (AOS). AOS format is not favorable to vectorization. Whereas Fortran, at least for the older programmers, tends to organize data dimensions (all X's, all Y's, ...) which is Structure of Arrays (SOA). SOA format is favorable to vectorization.

I'd vote for Fortran for computational side, but you may wish to use something else for the presentation side. It is relatively easy to write a mixed language application.

Jim Dempsey

[george_M_]

Thank you Jim. I believe that you confirm my understanding on the matter. Graphics with C++ and performance in handling large number of calcs through matrices and vectors with Fortran. 

[jimdempseyatthecove]

George M,

When you code using multiple languages, you have a new learning experience to go through with when both languages expect to be in control of the multi-threading capabilities. You will also experience this issue with a multi-threaded application together with a multi-threaded DLL (which may be both written to establish thread pools occupying all logical processors). For example, a multi-threaded may be best served by calling the single-threaded MKL library. IOW each of the applications multiple threads call (possibly the same) MKL function concurrently and in which the MKL function uses only the caller's thread (concurrency equals that of the caller's application space).

Jim Dempsey

[george_M_]

I believe that you can avoid mixed programming by developing the solver and the graphical interface  separately. When the graphical generates the input file it can call the solver to execute the solution and after the analysis completion the output can be imported into the post-processing graphical environment. Femap with NXNastran if I am not mistaken uses this type of structure. Thus complete separation is achieved in terms of programming languages.

[jimdempseyatthecove]

If (when) the two are integrated, as and example providing simulation time animation, it would be desirable to have concurrent multi-threaded computation together with multi-threaded graphical processing. Preferably, this should be done with a single thread pool. However, in mixed language situations, often is the case where the programmer unintentionally instantiates multiple thread pool. In the simple case you end up with 2x threads (over logical processors), in the worst case you could end up with (number of logical processors)**2.

Jim Dempsey

[george_M_]

Thank you Jim for all your feedback. Highly appreciated.

Regards,

George

[jimdempseyatthecove]

Additional input that may affect your implementation strategy.

I am a fan of Intel Array Visualizer (a discontinued product). My use is primarily for simulation time animation (IOW monitoring the progress of simulations as the simulation progresses). What I found as extremely beneficial of using AV over using OpenGL (either/both can be enabled in the application), is AV hooks in as a separate process using inter-process shared memory by way of memory mapped file. This effectively separates the simulation process from the display process. I would suggest you consider doing something similar by having the computation run as a Fortran process "piping" data by way of memory mapped file to a C++ process running OpenGL or DirectX.

In my simulator I went one step further, and could additionally output simulation snapshots to log file in the simulator process, while simultaneously running a viewer process which could be run on a different node in the network. This technique permitted viewer rewind and advance while simulation process continues to run and produce output. This technique removed the display overhead from the simulator, and also did not interfere with the simulation runtime in the event I wished to pause the display process to get screenshots or analyze data.

Jim Dempsey

[dboggs]

I have nothing to contribute to this discussion but want to thank all of you for the interesting comments.

I would love to see this question expanded to the use of Matlab. Not that I support Matlab, but my small department is flooded with newbies that only know--and therefore insist on using--Matlab. There are also reports abounding that it is very speed-competitive, or even faster, whenever the problem can be cast into matrix form.

And don't forget C as an alternative to C++ (at least for the computational part of course).

So I ask: is anybody here sufficiently familiar with Fortran, C++, C, and Matlab to intelligently comment further based on experience?

[TimP]

In cases where Matlab calls the MKL library to perform most of the processing, one would expect similar performance regardless of which language calls it. Where the time spent in learning how to use one of the compiled languages is counted, Matlab evidently could come out ahead.