Fortran 2003/2008

I see nothing in a search under 'Fortran 2003' -- hence this thread.

Is it the intention of Silverfrost to remain within the ambit of Fortran 95 syntaxt ? Or is an upgrade to a more Fortran 2003-like syntaxt possible in the near future ?

I ask as there appears to be a growing need to enhance the language with features from other languages as well as enable more inter-operability between languages.

Naturally, since Fortran's main users are either legacy or specialist high performance applications, it may well be that there is limited marketing attraction towards the more recent syntaxt changes.

But I'd be very interested in Silverfrost's position on this general question.

My good wishes for the New Year to all staff and users of Silverfrost.

FTN95 already contains a few Fortran 2003 features. ENUM has just been added but there are no immediate plans to add anything more.

Hi Paul,

does your answer mean that there will be no future development to Fortran 2003 and/or Fortran 2008?

In other parts of the forum the support of 64-bit processors is also discussed and it seems to that there will be also no development in this direction.

I think many of the users of Silverfrost's compiler are very, very interested in these (new) features.

What is the reason, to not go on with the development of Silverfrost Fortran?

Isn't there enough personal for development? Are you the last and only developer?

It would be very pity, to see the Silverfrost compiler leaving the market by this way!

Best regards (and still hoping for the future),

Detlef Pannhorst

I fully agree with Detlef. Don't let Silverfrost Fortran die.

Regards - Wilfried

I can only confirm what I have already written. There are no immediate plans to extend the Fortran but further development is not ruled out. There seems to be a greater interest in developing a 64bit compiler so this would have a greater priority but we would need to find a cost effective way to proceed.

As a long time Fortran user, mainly in the fields of numericsl methods and operational simulation, I consider the directions of Fortran 2008 to be the wrong directions for my interests. My view is that if you need these features, use C... I accept that this may not be a commonly held view, but I see the effort that is being placed in the development of the Fortran language as misplaced. Back in the 80's there was more emphasis on a more portable Fortran and provision of programming structures that were more robust. My view is that some recent trends fail on both these points. My impression of the development of .net is a good example that the development costs killed Lahey and certainly impacted on Salford. I think a lot of the features in 2008 would have a similar effect and have a very limited user base. My view of Salford is that it is the best compiler for doing code development, but falls short on run-time performance and extension to 64-bit. I want Salford to remain viable, so I would have a vote against 2008 features on this basis. I'm sure there are others out there who would disagree with this view, especially C programmers. I hope there remains a need for numerical calculations using Fortran.

John

(My vote for No 1 improvement task for FTN95 would be to improve performance, by including some new processor instructions that are commonly available since /p6 was implemented, especially vector instructions)

Dear John, I am not aware of the fate of Lahey and I'm not able to evaluate the costs vs benefits of the .net development, but I'd like to remark that the good interoperability between ftn95 and .net is the main reason (not the only one, of course) why I chose this compiler. And this is also the reason why I trust in a future 64 bit development. But I agree with you about the need of performance improvement, also in reading/writing files.

It's not appropriate for ordinary users like me to make bold suggestions on what ought be in or out -- I don't have to pay the Silverfrost bills.

It would be interesting however to see results of a good survey of active users of FTN95 through the world, what they'd add or subtract to the compiler and what gains or eases they'd expect from such changes.

As someone who writes 'Modern' Fortran, I think there is much to commend some of the newer features in Fortran 2003 and Fortran 2008. For the most part a good job has been done to provide the Fortran programmer with a rich set of features for implementing programs which don't lend themselves to procedural style, e.g. data centric or object oriented styles.

At the same time, the language is backwards compatible with most of Fortran 77 so legacy and 'dusty deck' codes can be compiled.

I would like to see the Silverfrost compiler add some more features of Fortran 2003, but it is not just the compiler that would have to change; the debugger (SDBG) would also need to be updated. To expect a full implementation may require a complete re-write of the compiler and debugger which is a big ask.

David, I see that you are embracing new programming styles. Unfortunately I am one of the older fortran programmers whose skills do not include 'procedural style, e.g. data centric or object oriented styles.'

John

John,

There is nothing wrong with well-written Fortran 77 style code. Unfortunately I see a lot of such code that is poorly structured and difficult to read (as well as code that is poorly structured, difficult to read, and wrong). I do find that using some of the new ideas in Fortran 90/95 allow code to be structured in a way that makes it easier for the programmer to convey meaning. However, I am very selective in what I use and a lot of my coding still looks like Fortran 77.

Unfortunately (or fortunately, depending on your point of view), the new object-orientated features in 2003 are not supported very well in compilers yet, so I only use these things in code I write to educate myself. The only 2003 features I use regularly are command line arguments, which Silverfrost already supports 😉 . And I don't even think about Fortran 2008 yet (its far too early) and co-arrays (!!!) for parallel programming just confuse me even though I understand MPI and OpenMP.

David,

I have obtained a copy of the Fortran 2008 draft, dated 2010-11-24. The introduction starts:

8 ... The purpose of this part of ISO/IEC 1539 is to promote portability, reliability, maintainability, 9 and efficient execution of Fortran programs for use on a variety of computing systems.

I did not read too far into the document before I was convinced that Fortran 2008 draft fails it's purpose. My apologies with my previous post, as I have a very cynical view regarding 2008. There is much in this new draft that is not relevant to what I do. This worries me as I don't understand what practical use this Fortran 2008 language would have. That being said, there are few people in my industry who do the type of work I do. Most think it can be done with Excel or Matlab, so maybe my approaches to numerical computing are becoming less relevant. Fortran 2008 is supposed to be the path forward ?

John

There's a lot of things in Fortran 2003/2008 that are there to support object-oriented programming, and, if you are not familiar with that way of doing things or the terminology involved, it can all seem a bit alien and unecessary.

The new features are discussed in these documents fron NAG's website.

New features of Fortran 2003

New features of Fortran 2008

Almost all the good things from Fortran 77 are still in the language (a few things are obsolete) and there is no need to use the new things if you dont want to.

Amongst the good things in 2008 are some of the new intrinsic functions, especially the scientific/engineering functions bessel_j0, bessel_j1, erf, erfc, gamma, hypot, norm2 etc.

I avoided Fortran 90 for years, but when I eventually decided to experiment with some of the new features my programming style slowly began to change, and has now transformed quite considerably. I find that my scientist colleagues, who are traditional traditional Fortran 77 users, now do not really know what to do with my programmes, but my programmer colleagues, who generally have other language backgrounds, find them much easier to work with. However, this convergence of form is not the main advantage - the new features have made it possible to construct programmes that I would have considerable difficulty to programme in Fortran 77. So I am a big advocate for keeping the compiler up-to-date with the new standards. I am not so excited by some of the new intrinsic functions - there are libraries available for some of those - but features such as object-oriented programming support, and C-interoperability, for example, are very helpful.

If ENUM has been added, as Paul indicates, then the F2003 extensions help page in Plato is out-of-date. Are there other features that have been implemented that are not listed there?

I suspect that there are not many new people learning Fortran nowadays, and that of those of us who do know the language, only a few are bothering to learn how to use the new features.

As someone who has code that takes a week to run on a very fast Xeon, do concurrent and coarrays look very attractive. I know very little about compilers but both of these seem like they would be difficult to implement. If I'm wrong and they are relatively easy, I would lobby hard for them as multi-core computers are very much the norm these days and my code is essentially incompatible with the structure of GPUs.

My limited experience with multi-core has not been good. A better solution is probably to use third party libraries. I don't have experience of linking them to FTN95, but Dan has had some success. He has mentioned equation.com and there are also other libraries that claim to have multi-processor capacity. I'm not sure on their general availability. The communication and process control is a significant problem and run time overhead for someone new to the field. Existing solutions are available, but I am not sure how accessible. This is an area I am wanting to better understand and sounds like it would help your problem.

John

Most of F2003 and F2008 additions to Fortran are cool options. They should attract new programmers and keep busy existing. Because we all like cool stuff.

Our Fortran 'fathers' (excluding some lucky with supercomputers) did not have several things we all have today - we've got color graphics and GUI, multiprocessing and a lot of memory. So Fortran language to be 'cool' has to address that in its Standard.

It did not or barely did so far so developers were adding new features at their own risk as non-standard options. Now Fortran community in general has got

• GUI
• multiprocessing
• and some started to add 64-bit addressable space

With FTN95

• we have GUI builder Clearwin+ with graphics libraries and OpenGL, we also can use (and other compilers can use too) Winteracter or GINO.
• we can use multithreading or third party parallel libraries for multiprocessing (though DO CONCURRENT and COARRAYS would be better from the point of view of the source being standard conforming, but professionally made libraries could be still faster - i for example get 8-10 times speedup with 4 cores)
• but we can not get through 4 GB limit even with any third party options while every entry laptop in the market has even more memory.

For me, adding 64bitness would be most usefull next coolness and its time came right of today. Down the road more and more people will jump over 4GB limit so this is exactly an important feature, and it lies exactly on the right trend.

As to other 'coolnesses' we have a lot of it already with this compiler people yet do not use or even do not know. Fun is that some new F2003/F2008 standard features exist in this compiler from i think Fortran77 circa 1990. The not exact but by sense close analog of DO CONCURRENT multithreading for example. As well as interoperability with C. And it still has something more -- like partial interoperability with HTML, NET, ability to call system functions which even F2020 will not have.

Cool would be also to have more networking capabilities besides some initial which would be 4th major additions our fathers did not have. And object oriented features. Again this can still be partially done with outside software if its absence kills you. But unfortunately no way we can get 64bit space with any trickery or third party software. So if we'd vote, my wish would be 64bit first, adding parallel options of F200X second, optimization of execution speed to match leaders third.

In my experience, Fortran programs which take benefit from multi-processor and multi-core processors are most easy to implement using OpenMP compiler directives. Speed-up factors of 3-4 are achievable on quad-core computers, speed-up factors of 9-12 are achievable on 2 processor 6-core computers (i.e. 12 cores), but actual performance depends on the actual Fortran code.

A code written using OpenMP will compile and run under FTN95 but will just use one core/processor. This can therefore be used for development and debugging/testing, and a different compiler used to take advantage of the multiple processors.

David,

My limited experience with OpenMP has not been as successful as you have presented. What numerical problem and algorithm have you been solving ? I have been applying OpenMP to a direct solution of linear equations, using a skyline solver, but have had problems with the multi-processor overheads. I'd expect itterative solvers are more suited to distributed processing and OpenMP. To improve my attempt, I am told I would need to expand the scope of the OpenMP code to reduce the overhead but that doesn't appear possible for my existing code. Not as easy as I had hoped. However, I have found that the vector instruction set has been more effective and easy to implement. I'd be interested to hear more of your experiences with OpenMP.

John

Hi John,

Most of the time I use OpenMP in applications where there is little or no communication between the different threads, like Monte Carlo simulations where a lot of calculations need to be done independently. These codes are close to being 'embarissingly parallel' and performance scales linearly with the number of cores (up to 12, I can't go any higher). However, I have had some success parallelising LR and Cholesky factorisations (factor of nearly 2 on a dual core laptop).

Often its easy to parallelise at the deepest level (innermost loop) but this won't give you good performance, since the work needs to be significant compared with the overhead of managing the threads. You have to parallelise at an outer level somehow. The innermost loops are where you may be able to get some extra benefit from vectorisation.

All this means is it depends on the algorithm and how easy it is to parallelise it. I haven't looked at skyline storage and solving such equations unfortunately.