choice of Fortran vs other HPC language for new software development

[DataScientist]

Dear Intel Fortran team, and Steve Lionel,

I am a member of a computational research group and I have been appointed to develop an agent-based model from scratch for some biological processes. I am very much fluent in Fortran, and in love with it, obviously for its efficiency in number-crunching and really nice math and array-handling tools.

However, I seems like C++ is gradually gaining some momentum in the world of HPC and I have heard of some rumors that object-oriented Fortran codes may not be as efficient as OOP in C++.   Is this a myth or reality?

Also, since our software is expected to be scalable and well-maintained over the following years and perhaps decades, I wanted to know about Intel's plan for supporting Fortran in future.

If you have any advice or comments on why I should choose or not choose Fortran against C++ for OOP, I'd appreciate it very much.

Can I rely on coarray feature in Fortran for parallelization of the code in future? How would you compare it with MPI? The coarray feature is one of the reasons I'd like to continue with Fortran.

A. K.

[jimdempseyatthecove]

Considering that most HPC oriented applications run on processors with relatively wide small vectors, 256-bit and/or 512-bit capable of holding 8/4 floats/doubles and/or 16/8 floats/doubles, it appears somewhat oxymoronic to use OOP and HPC at the same time in describing an application. HPC on these systems tend to work best using VOP (Vector Oriented Programming). When performance matters, and the problem can be expressed using vectors (SIMD capable vectors), then you will have to redefine your definition of OOP.

IMHO the OOP level would be for an opaque container of objects, that are internally stored as Structure Of Arrays with the container having getter/putter for manipulating individual objects extracted by value, and container-wide operator functions that internally use SIMD on the re-composed vectors of properties. In C++ OOP, the outer layer of the OOP onion typically have collections. As an example a collection of particles. And the collection has a list of operator/member functions that perform operations on the collection. Typical C++ OOP carries the object paradigm deeper into the collection than what is suitable for SIMD operations. I recommend that you not do this for HPC programming.

Jim Dempsey

[TimP]

As Jim said, the usual culprit for lack of performance in OOP is data structures not amenable to SIMD vectorization.  That applies equally to Fortran and C++.  No doubt, some C++ programmers are learning to make accommodations between OOP and performance.  The very few publications which claim to bear on your desire to compare Fortran and C++ OOP seem to fall short.

It's hard to answer your question about coarrays,  A few of the vendors supporting them have made the effort to make them fully interoperable with MPI, so then it can be seen as a way to get some MPI facility with more appealing syntax.

It's not clear (to me) that coarrays will be made fully compatible with the requirement of architectures like Intel(r) Xeon Phi(tm) to use all available levels of parallelism, including OpenMP as an intermediate layer between SIMD and multiple image (MPI/OpenMP hybrid).  But I don't know whether that is part of your question.

[FortranFan]

A.K. wrote:

.. If you have any advice or comments on why I should choose or not choose Fortran against C++ for OOP, I'd appreciate it very much.  Can I rely on coarray feature in Fortran for parallelization of the code in future?  ..

First of all, is it possible for you to explain what you mean by "HPC" and what does performance really mean in your context?   Or at least, can you confirm you have absolutely verified your needs are truly HPC involving floating point computations approaching or exceeding teraflop range?  This may prove quite important because if it is truly HPC, then OO analysis, design, and implementation may go one way with very limited use (or none at all) of the OO paradigm in order to ensure minimal impact on the HPC aspect.  Whereas if your situation is not that compute-intensive, then much fuller OO paradigm may be amenable in order to yield the usual benefits that are particularly important with respect to all the human aspects of software package development, maintenance, support, etc.  So you may want to be clear and honest for yourself on this matter.

See this thread and the paper referenced therein for some comments and comparisons on programming approaches involving Fortran and C++: https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/509099.

Also, in case you are not familiar with some recent material, you may want to review those recommended on the Dr Fortran blog: https://software.intel.com/en-us/blogs/2013/12/30/doctor-fortran-in-its-a-modern-fortran-world, in particular the books by Hanson+Hopkins as well as the one at the bottom of the blog by Rouson et al.

If you search online, you will also find Rouson et al. to be very active in the coarrays arena, especially OpenCoarrays and making a lot of advancements available at GitHub: https://github.com/sourceryinstitute.  Rouson is also on the Fortran standards committee now and he can inform you a lot on where Fortran standard would evolve in the area of coarrays.

You may want to touch base with Rouson et al. and with Hanson, Hopkins and get their views on your needs, if possible.

Also, you may want to post your thoughts on comp.lang.fortran forum and seek feedback there: Rouson and other Fortran practioners do follow that forum and may offer useful comments there.

Do take into account your development team and their current and future backgrounds: is this a large team, meaning a lot of collaboration or a small group (1 to several) of coders?  How important are the toolsets that cover the entire code development cycle?  Sadly Fortranners often cannot avail themselves of the full rich set of tools that others, particularly C++ coders, typically have (IDEs, "intelligent" code editors, profilers, code documentation tools, etc.).  After a while, it can all start to impact productivity - so you may want to keep this in mind.

But then also, consider the background of your coders in the team.  If it includes heavy computer science and numerical types, then C++ is truly an option.  But if the team is mostly technical subject matters with limited coding experience, then the complexity of C++ can be a huge risk, if not managed very, very carefully.

Finally, I suggest you put together a small prototype of your needs, if you haven't done so already.  If you can miniaturize your needs and create a minimal working example (MWE) for it, you might find it very useful.  And then consider coding it up in both Fortran, C++, etc. for comparison and illustrative purposes.  I typically do and find it very beneficial.  One recent example for me was a simulation need which the consumers thought was HPC but in fact it wasn't; it involved a lot of calculations but it got nowhere close to the teraflop range.  Most of the simulation time was consumed in a custom library involving quadratures.  I put together a MWE involving a simplified representation of the quadrature computations and was able to show there was little difference computationally if it was done in C++ or Fortran.  What mattered most were other aspects involving the background of the technical experts who would maintain the calculation libraries, especially one involving quadratures, and also other elements such as systems integration for data exchange, post-processing including visualization, and the user interface.  Ultimately a mixed-language solution turned out best which made heavy use of standard C interoperability features in Fortran, but also C++, HTML5, SQL (for database), etc..  So you may want to open to such a heterogeneous language design as well.

Good luck,

[Michael_S_17]

I am not from Intel, hope you don't mind, still giving my personal answer to your question.

As a Fortraner I would recommend Fortran of course ;-). Nevertheless, I believe that build-in parallelism will become state-of-the-art for every major programming language shortly, and coarrays are not limited to Fortran. There are already several prototype coarray implementations for C++ and one for Phyton (Co-array Phyton), see this paper from Troy A. Johnson for an example:

http://www.pgas2013.org.uk/sites/default/files/finalpapers/Day2/R4/2_paper6.pdf

Other Coarray C++ examples are:

http://www.researchgate.net/profile/Jose_Moreira4/publication/220951575_A_C_Implementation_of_the_Co-Array_Programming_Model_for_Blue_GeneL/links/02e7e520ed7dc3264e000000.pdf

http://static.ph.ed.ac.uk/dissertations/hpc-msc/2012-2013/An%20implementation%20of%20the%20Coarray%20Programming%20Model%20in%20C++.pdf

These papers may also answer some of your further questions and give great insights into the rationale of Coarray Fortran as well.

Regards

Michael