Is *explicit* better than implicit?

[szaghi]

I feel that there is an almost unanimous agreement on that implicit none must be mandatory, but I guess many of you will provide interesting exceptions, so

do you agree to advice to be explicit?

In the case you disagree, please elaborate your idea.

[zbeekman]

I think @muellermichel's suggestion of marking recommendations with their compiler compatibility is a very sad, but required necessity. We should make sure we include the version numbers too, in the event that the list doesn't keep pace with compiler releases.

I also think that it is important to strike a compromise between portability and "modern-ness" on the one hand I don't think that you should write new code assuming the worst, most antiquated systems should be able to run it; if you did that you'd be stuck writing Fortran 77! On the other hand, some features just aren't supported (even if they claim to be) by compiler vendors, and this can cause a real headache.

If only there were a tool that would help translate modern Fortran into something more widely understood by todays compilers, to free us from the tyranny of the slow/crummy implementation of new language features...

[cmacmackin]

Well, if you want a modern language which can be converted into an older one, there's always Vala, which gets translated to C before being compiled. Not really relevant, but it's a cool project because it is an object-oriented language which can produce (as well as use) libraries written in C. It also has C-like performance, apparently. It would be entirely possible for people to write a similar tool for Fortran, though not enjoyable... I certainly am not nominating myself!

[rouson]

Portability versus modernness is a very difficult question and I'm not confident there is one reasonable answer that can be clearly be identified as the correct answer (or even the consensus answer) in the abstract (meaning without a funded project with deadlines to drive the decisions). I'll offer that one of the best pieces of advice I ever received was from the review my publisher solicited when I submitted my book proposal. I was planning to use Fortran 95 to emulate OOP in my book. The reviewer commented, "If you really want the book to have lasting value, use the OOP features of Fortran 2003." That was early in 2007 and I didn't know of any compilers that supported the OOP features of 2003 at the time. It took upwards of six months to find out that IBM supported the features and to find IBM compiler test team engineer and Fortran standards committee member Jim Xia to work with me on learning the features and writing a journal article on design patterns in modern Fortran.

Arguably that reviewer's one comment had a greater impact on my career than any other single sentence of advice. It is a very large part of why I'm doing what I'm doing today.

If we want our work to have lasting value, I suggest we choose modernness over portability, assuming portability is defined by the ability to use a wide range of compilers.

Alternatively, if portability is defined by the ability to use a wide range of hardware, I suggest that most of Fortran 2008 and even a goodly chunk of Fortran 2015 can be used on a very wide range of hardware if one installs the current development branch of gfortran. And for many people who would be uncomfortable installing the development branch themselves, I suggest installing OpenCoarrays, which will install gfortran for you if it does not detect gfortran in your path or if the gfortran version in your path is old. (@zbeekman, let's get that next release out the door. ;) )

[szaghi]

@muellermichel wonderful idea!

@zbeekman I agree.

@rouson I think that Fortran 2003 is sufficient mature to be considered widely supported, do you agree?

I am not stressing all 2003 features and I am not using many 2008 ones, but my feeling is that with Intel, GNU and IBM compilers the way to 2003-modern-ness is feasible (I am facing with some bugs, but workarounds exist).

I still think that portability, understood as a synonim of practicality, counts more than modern-ness at the end. For example, I would very very like to try Parametrized Derived Type, but its support is so limited that my portability/practicality considerations stop me to try.

P.S. OpenCoarrays rocks!

[rouson]

On Jan 22, 2016, at 7:55 AM, Stefano Zaghi notifications@github.com wrote:

@muellermichel https://github.com/muellermichel wonderful idea!

@zbeekman https://github.com/zbeekman I agree.

@rouson https://github.com/rouson I think that Fortran 2003 is sufficient mature to be considered widely supported, do you agree?

I am not stressing all 2003 features and I am not using many 2008 ones, but my feeling is that with Intel, GNU and IBM compilers the way to 2003-modern-ness is feasible (I am facing with some bugs, but workarounds exist).

I would go much further than that. I don’t think we should let any one particular compiler hold us back when there exists a free, open-source compiler that is easily installable on nearly any hardware. Adopt gfortran and let the rest of the compiler vendors spin their wheels trying to catch up. I grew weary with waiting and trying to come up with a common set of well-supported features. I just won’t live that way anymore.

Moreover, parallelism is of paramount importance in the multi-core, many-core era. In that regard, coarray Fortran is a game-changer. The power of being able to write code with no reference to external libraries and have that code scale from a dual-core laptop to a 100,000-core supercomputer is just too much too big a deal to ignore. You can do that today with gfortran (and with Cray).

I still think that portability, understood as a synonim of practicality, counts more than modern-ness at the end. For example, I would very very like to try Parametrized Derived Type, but its support is so limited that my portability/practicality considerations stop me to try.

I always find it a bit confusing that people use the word to mean “using the feature with different compilers” rather than “using the feature with different hardware”. In the mainstream, non-technical world, I think most people use the term “portability” to mean moving objects physically from one place to another. It is only in the Fortran world that the unevenness of compiler support has forced us into the is awkward use of the word to mean moving code across compiler space. Most importantly, if we choose this awkward use of the word, then we will make decisions today that will seem outdated next year or the year after.

Damian

[muellermichel]

Alternatively, if portability is defined by the ability to use a wide range of hardware

Yes, that's how I meant portability. I would actually narrow it down further: Look at the Top 100 list, take out the systems that have been introduced or upgraded in the last, say, 3 years and look at their architecture - what compilers / versions can they support?

I suggest that most of Fortran 2008 and even a goodly chunk of Fortran 2015 can be used on a very wide range of hardware if one installs the current development branch of gfortran.

Here's where I don't agree: Today we should get ready for hardware architectures with increasing amounts of shared memory parallelism, namely today Tesla cards and Intel MIC, but it could be a number of other architectures further down the road. At least with GPUs we are limited to (a) Cray systems with Cray or PGI compiler or (b) other systems with PGI compiler. Gfortran just isn't an alternative there, and probably won't be for quite some time.

[zbeekman]

@muellermichel : OpenCoarrays is actively working on supporting these architectures; the future may be closer than you think!

[muellermichel]

@zbeekman : Interesting to know. How soon would you guess can this be ready for production? By that I mean support for all relevant modern GPU features like unified memory, GPUdirect, dynamic parallelism; furthermore support for different storage orders used for different architectures, and last but not least support for at least one usable debugger and profiler, and all that without breaking for large codebases. I've had quite some experience with OpenACC now, which strives for these goals at an IMO more modest level and IMO it is not stable enough for large codebases like, say WRF. The amount of stuff that still breaks between each point release is tremendous.

[szaghi]

@rouson

I would go much further than that. I don’t think we should let any one particular compiler hold us back when there exists a free, open-source compiler that is easily installable on nearly any hardware. Adopt gfortran and let the rest of the compiler vendors spin their wheels trying to catch up.

:smile: I agree, GNU gfortran is my preferred compiler now (again).

I always find it a bit confusing that people use the word to mean “using the feature with different compilers” rather than “using the feature with different hardware”.

Indeed, I would like to be totally unaware of compiler and or hardware: in my Utopia I would like to deal with only Fortran, but as @muellermichel stated above, the reality is more sad.

I think most people use the term “portability” to mean moving objects physically from one place to another.

This is not my case: I use portability often in the contest move the code from one architecture to another. In particular with architecture I mean the available combination of hardware/compiler. In the past I have faced with the impossibility to select my preferred compiler, thus porting the code from my architecture to another was problematic (there were some non standard codes). In my mind, being standard = being portable = being practicable (what an approximation of English I am using... order -10).

It is only in the Fortran world that the unevenness of compiler support has forced us into the is awkward use of the word to mean moving code across compiler space.

Yes, but I think that we coarrays is changing many things in this regards: they are a standard way to exploit the hardware being unaware of the hardware itself. At least, this is my hope.

[rouson]

@muellermichel, if you're considering using coarray Fortran (CAF) with gfortran on the architectures you mentioned, then I suggest posting to the OpenCoarrays Google Group or emailing us at opencoarrays@googlegroups.com and describing what you'd like to do. I think you have to subscribe to post, but it's a very low-volume list. The most recent message was on 17 December. As @zbeekman, it might not be as far off as you're thinking and there might even be some existing capabilities you could use if you clone the repository. Alessandro has done some encouraging testing on Intel MIC and is working on some support for offloading to NVIDIA. I'm certain there is a long road ahead, but it's likely that more has been done already than you're imagining.

If you're talking about non-CAF calculations, then I'm less knowledgeable, but I would then suggest emailing the gfortran mailing list to describe what you want to do. Again, I think there might be more there than is widely known.

[SourcerersApprentice]

On 1/22/2016 1:00 AM, Chris MacMackin wrote:

There is a branch of GDB which can handle at least some of the F90 features, although I can't remember off the top of my head whether it can manage pointers.

GDB's pointer management is present, but incomplete. They have not supported pointer members of a derived type yet. Despite this lack of support, I would otherwise say that GDB is one of the best debuggers I have ever used as far as the feature set is concerned.

Also, which commonly used vendor (other than GFortran) isn't associated with a hardware manufacturer? NAG, I guess, but they aren't that big a player. In my opinion, the only "commonly used compilers" at this point would be Intel and GFortran. Cray and PGI are limited by their hardware dependence and I think of them more as boutique players. Other vendors I had in mind were names like Absoft, NAG, Lahey and Salford. The fact that they are not commonly used is a reflection of the fact that they were not able to keep up with optimization technologies or make the jump to Fortran 2003, and this is why in my opinion they are eventually doomed. I forget where I heard this, but a few years ago there was a prognistication circulating that in 10 years, the only players left in the mainstream PC market would be Intel and Gfortran. A couple of years down the road now, it still seems to me like things are heading that way.

[nncarlson]

Other vendors I had in mind were names like Absoft, NAG, Lahey and Salford. The fact that they are not commonly used is a reflection of the fact that they were not able to keep up with optimization technologies or make the jump to Fortran 2003.

No way would I put NAG in that category. Their 6.0 compiler is nearly complete 2003 (defined input/output is the only thing it is missing that I can think of) and many 2008 features (but no submodules or coarrays) and what it does have is solid. You can't say that for GFortran; its got far too many bugs with 2003 features (It doesn't work for me) and progress on fixing them is glacial.

[SourcerersApprentice]

On 1/22/2016 8:06 AM, Damian Rouson wrote:

I would go much further than that. I don’t think we should let any one particular compiler hold us back when there exists a free, open-source compiler that is easily installable on nearly any hardware. Adopt gfortran and let the rest of the compiler vendors spin their wheels trying to catch up. I grew weary with waiting and trying to come up with a common set of well-supported features. I just won’t live that way anymore. I have to agree here that the existence of GFortran means we can use modern Fortran features without fear.

I always find it a bit confusing that people use the word to mean “using the feature with different compilers” rather than “using the feature with different hardware”. In the mainstream, non-technical world, I think most people use the term “portability” to mean moving objects physically from one place to another. It is only in the Fortran world that the unevenness of compiler support has forced us into the is awkward use of the word to mean moving code across compiler space. Most importantly, if we choose this awkward use of the word, then we will make decisions today that will seem outdated next year or the year after. I have to admit I have always thought of "portability" as movement between compilers. From my point of view as a Fortran programmer, I expect architecture to be hidden by the compiler, and differences in architecture should not affect how I write my Fortran code. I also think of "portability" as synonymous with "standard conforming", and I have "portability issues" if I have needs the standard does not address. However, if I take off my Fortran programmers hat and put on my compiler makers hat, everything changes and my opinions now better align with the above statement.

[rouson]

On Jan 22, 2016, at 11:35 AM, Neil Carlson notifications@github.com wrote:

No way would I put NAG in that category. Their 6.0 compiler is nearly complete 2003 (defined input/output is the only thing it is missing that I can think of) and many 2008 features (but no submodules or coarrays) and what it does have is solid.

I agree.

You can't say that for GFortran; its got far too many bugs with 2003 features (It doesn't work for me) and progress on fixing them is glacial.

What version are you using?

If the related bugs have been reported via gfortran’s Bugzilla site, then please post a list of the ID numbers. My experience on bug fixes as been the exact opposite. I reported one bug in the Fall that was fixed within 24 hours and another that was fixed within 48 hours. A certain amount of it is probably related to distilling the bug reports down to very isolated demonstrators (15-20 lines is optimal and nearly always achievable with sufficient effort). Another big chunk of it probably relates to the fact that I have on a small percentage of occasions used project funds to pay a developer to fix one or more bugs.

If organizations pay for a license for commercial compilers, then it’s reasonable that they pay occasionally for support on an otherwise free compiler.

To be sure, I have also seen some bug reports languish with gfortran, but fortunately for me, there haven’t been any that were showstoppers and I think that’s a pretty strong statement given the broad cross-section of Fortran 2003, 2008, and even 2015 that I use regularly.

Damian

[SourcerersApprentice]

On 1/22/2016 11:35 AM, Neil Carlson wrote:

Other vendors I had in mind were names like Absoft, NAG, Lahey and Salford. The fact that they are not commonly used is a reflection of the fact that they were not able to keep up with optimization technologies or make the jump to Fortran 2003.

No way would I put NAG in that category. Their 6.0 compiler is nearly complete 2003 (defined input/output is the only thing it is missing that I can think of) and many 2008 features (but no submodules or coarrays) and what it does have is solid. You can't say that for GFortran; its got far too many bugs with 2003 features (It doesn't work for me) and progress on fixing them is glacial.

— Reply to this email directly or view it on GitHub https://github.com/Fortran-FOSS-Programmers/Best_Practices/issues/10#issuecomment-174021557.

I am not too familiar with the NAG compiler, and in light of this information would remove them from this list.

[rouson]

On Jan 22, 2016, at 11:44 AM, SourcerersApprentice notifications@github.com wrote:

I have to admit I have always thought of "portability" as movement between compilers. From my point of view as a Fortran programmer, I expect architecture to be hidden by the compiler, and differences in architecture should not affect how I write my Fortran code. I also think of "portability" as synonymous with "standard conforming", and I have "portability issues" if I have needs the standard does not address. However, if I take off my Fortran programmers hat and put on my compiler makers hat, everything changes and my opinions now better align with the above statement.

Thanks for sharing this perspective. I’ve had such a hard time relating to the common uses of the word so hearing more perspectives helps. I even hear people use the word for simply adding or swapping features, e.g. porting to coarray Fortran from MPI. Clearly the word has been overloaded with a lot of meanings.

Damian