This event should be of interest to the Fortran community (registration link is on the page):
4 Likes
Thanks for sharing. I listened in, and thought the webinar was very well done.
1 Like
They mentioned templates that would be very cool if they could implement it. They said it is “hard” or even “very hard”.
I think it’s definitely very hard to design them, and that’s where we are still. But to implement an existing design doesn’t seem so hard, but it depends on the internals of the compiler. I am estimating around 90% of my time was spent on design. The implementation itself took maybe 10% so far. I am sure it will go up once the design is settled and we need to fix every corner case.
2 Likes
For all interested, the webinar recording is available here.
Yes, I heard the comment(s) at the Intel Town Hall re: templates too and noticed that too and I was both tremendously disappointed and flabbergasted.
I’m sure there’s “truth” to the comment(s) re: it being “hard”.
But the ground reality then is a damning indictment on the state of Fortran overall and the overall Intel’s commitment to Fortran.
The sentiment of it being “hard” conveys a terrible, terrible, terrible impression of Fortran.
Because, for one, the “truth” can also seen as in year 2023, decades after so many, many programming languages have designed and implemented templates and its general principles and concepts and design are sophomore or earlier teaching aspects in so many computer science and engineering programs globally, the fundamentals are especially well-established. It’s only a failure of imagination or technical lethargy can make it seem as “hard”.
Re: the failure of imagination, consider just one scenario: energy needs and industry for humanity over the next 100 years, it’s a profoundly important aspect for basic human existence. The entire edifice toward humans and their lives will be based on the climate effects with climate modeling playing a monumental role in all decisions.
A digression here: think of Hidden Figures and how Fortran got its boost.
Currently about the only meaningful global domain and endeavor where Fortran retains some significance is climate modeling.
But now globally, the world requires massive investment to address climate, per the laptop class which also includes all Fortranners.
The estimate is >US$ 1,000 TRILLION globally over the next 100 years. Supposedly the very survival is as stake.
Now, as I mentioned above, almost the decisions and effort will be driving by computational science and modeling, for effectively every effort towards the investment.
This is the real hard stuff.
This will require massive application development and so many industries, especially the energy industry, will spend gazillions on coding.
Yet think of any IT coding technology lead or manager who needs to make investment decisions re: programming and app development.
They hear Fortran and Intel finds it “hard” to do templates during the 2020s and truth and nothing but truth will be Fortran will be low on priority or not at all under consideration.
And if Fortran won’t be of much significance then in the most urgent matter for 21st century, seriously why bother?
Why Fortran, For What?
I was also present. It was nice to see the arrival of memory and address sanitizers.
There were several interesting questions posed about do concurrent toward the end, but unfortunately the time ran out before we could get answers.
Related to that, wildfires are also getting worse according to NASA and ESA. If one thinks about the wildfires in 2023 and associated loss of forest, carbon dioxide emissions, air pollution, and also loss of life (both human and animals), an investment into improved wildfire modelling appears necessary. Now this is quite niche area, but AFAIK, the most mature software in this field is the Fire Dynamics Simulator, written in Fortran.
Electronic structure theory, quantum chemistry, are large consumers of Fortran, at least in academia. These fields are linked to designing improved materials/molecules for whatever purpose (energy, medicine…).
2 Likes
I would also be interested in those answers, as I am not sure what is the purpose of DO CONCURRENT.
As I suggested recently, is DO CONCURRENT making the same mistake as FORALL ?
I don’t see the supporting infrastructure in the Fortran standard to enable the suggested efficiency gains to be realised. It would be good to hear from compiler developers as to where this approach is or could be heading.
Could there be some merging of DO CONCURRENT with OpenMP ?
It looks like the OpenMP approach is moving further away from any possible Fortran standardisation with further niche GPU off-loading.
Or is Coarray Fortran the way forward ?
An area worth more discussion ?
This seems to be more or less the case currently. Intel uses OpenMP behind the curtains to enable DO CONCURRENT.
nvfortran enables mixing OpenACC with DO CONCURRENT to mix less-verbose code + better data control flow.
I guess the take away is that, while DO CONCURRENT is in its infancy, compiler editors try to load parts of the external standards within.
I don’t think one can make such overlap. While Coarray Fortran can be used in a shared memory approach, its main purpose is to enable distributed memory (à la MPI). DO CONCURRENT is targeting shared memory (multithreading/vectorization) parallelism.
Definitely!!
1 Like
I would say it is not complete, so why is it in the standard in an incomplete form ?
This is the same approach that gave FORALL such a short life.
I have been using (only a small part of) OpenMP for 8 years and it is a way to significantly improve computation performance. It should not be ignored by the Fortran standard, especially as “computation performance” is seen as a strength of Fortran. ( and please include default(none), which auto parallel approaches don’t appear to have )
There is good OpenMP support in modern Fortran compilers.
Furthermore OpenMP is also standardized, so your Fortran+OppenMP code remains portable.
Therefore I would not be surprised if many Fortran programmers consider OpenMP already as de-facto part of Fortran.
(I do, but of course I can not speak for other users).
I wouldn’t put do concurrent and forall in the same basket… and the kid can already accomplish that much, even if not as mature as its father (OpenMP)… from what I’m understanding so far is that the promise of do concurrent is that: At worst it would default to just a regular do, in principle, it would (should/will/?) enable you to do exactly what you are already doing with OpenMP but dropping all those extra lines of code with the directives.
The thing you should accomplish with it, is coding once, and running your same (cleaner) code on CPU with multithreading or on GPUs. Instead of having to pileup OpenMP and OpenACC simultaneously…
I’ve found these references quite nice:
Something that does intrigue me is that I’m understanding that if one uses do concurrent, then either the code will be multithreaded on the CPU or offloaded to the GPU, but what about a hybrid code in which one would like to have more control on which hardware is processing the data? … Maybe it would be needed to have something à la pytorch like “todevice = gpu/host” as extra argument?
I have been reading further and am now confused as to when should a Fortran compiler make a DO CONCURRENT loop multi-threaded ?
(My earlier Gfortran V11.1 tests did not use sufficient correct/appropriate compiler options for DO CO… to be multi-threaded. Is that ok?)
Practically, I would expect the “TownHall” DO CONCURRENT example would never run faster by being multi-threaded, or off-loaded.
I wonder what extra instructions need to be provided in Fortran to achieve improved performance with DO CO… I see that “locality-spec” provides some management of variable, but this is more important for achieving a correct result.
Scheduling can be very significant for !$OMP DO for performance improvement from cache coherency, but this may conflict with Do Concurrent’s “no interdependencies between loop itterations”
Some Fortran users still use FOR ALL, as they like the concise syntax. Perhaps DO CONCURRENT will be the same.
As a proficient user of OpenMP, I can’t identify where DO CONCURRENT would be preferred.
When does DO CONCURRENT improve Fortran, or should we go straight to Fortran+OpenMP ?
DO CONCURRENT just opens up the possibility (among other possibilities) of multi-threading the loop, but the compiler has no obligation to do so.