Please, No More Loops (Than Necessary): New Patterns in Fortran 2023

1

There will be a potentially nice talk by Fortran Standards Committee member @Damian Rouson on HPC Best Practices, with the same title as this post. The webinar registration link for interested Fortran programmers: https://www.zoomgov.com/meeting/register/VNMWsQl6SjeYrHAfFh-miA#/registration

Please, No More Loops (Than Necessary): New Patterns in Fortran 2023

1:00 pm - 2:00 pm EDT

Wednesday, January 21, 2026

Presenter: Damian Rouson (Berkeley Lab)

Description:

Loops are seemingly ubiquitous in programming and yet writing loops provides one example of a common practice stuck in a pattern as old as high-level programming languages themselves. This webinar will provide an overview of the features introduced in Fortran standards from Fortran 90 to 2023. We will venture into often-unvisited nooks and crannies and traverse equally unvisited expansive pastures. Weaving feature groups together by the approaches they enable, the talk will emphasize array, object-oriented, parallel, modular, and functional programming patterns and paradigms. The talk will demonstrate the utility of the described features in open-source packages developed by Berkeley Lab’s Computer Languages and System Software (CLaSS) Group and our collaborators. The presentation will emphasize expressiveness and conciseness, showing how our Julienne correctness-checking framework supports writing assertions and unit tests using natural-language idioms; how we write textbook-form partial differential equations (PDE) in the Matcha T-cell motility simulator; and how we concisely capture advanced algorithms for training neural networks in the Fiats deep learning library. The talk will include a brief update on the status of the compiler and runtime-library support for these features in the open-source LLVM flang compiler and the Caffeine parallel runtime library developed by CLaSS and our collaborators. The talk will conclude with a description of the planned Fortran 2028 support for generic programming via type-safe templates and the powerful ramifications of this technology in our development a formally verifiable, domain-specific language embedded in Fortran 2028 via a type system being developed for the MOLE PDE solver library. One recurring theme will be the ability to write thousands of lines of code manipulating large collections of data with few or no loops.

7 Likes
2

I look forward to the talk, but one of Fortran’s strengths is that you can use array operations to concisely express some algorithms (as with NumPy) and loops when needed (as with C or C++). By contrast, Python loops are slow, and C++ does not have array operations with the same flexibility of Fortran, in which code with array operations and loops is comparably fast. But maybe I will learn about algorithms that I thought required loops but do not. Fortran does have do concurrent.

3 Likes
3

I think the trick Damian uses it declaring most things as elemental so that you can do an “implied” loop from the elemental procedures, which I think are mapped to a loop ish depending on the compiler (I believe). And do concurrent around an elemental function/subroutine can be offloaded to a GPU

3 Likes
4

Interesting. But do concurrent does not require elemental subprograms, they can be pure. Moreover, my understanding is that do concurrent does not eliminate any loop, it just tells the compiler that the loops are independent and therefore can be parallelized (similar to the now obsolete forall)

5

While I like using elemental procedures (the only case where I preferer a function rather than a subroutine), the issue is that as of now one can not rely on that simple fact to create proper and performant libraries because: if the procedure is placed under a module in a file my_mod.f90 and use it somewhere else (some_other_file.f90 > use my_mod, only: my_nice_elemental_proc), this procedure won’t be inlined (unless using-ipo/-flto, which come with their baggage of build time complexity).

Would be interesting to know if this discussion has moved any further Add keyword to support inlining across modules · Issue #229 · j3-fortran/fortran_proposals · GitHub

2 Likes
6

I like using FORALL because it often requires fewer lines than the alternatives, so that a block or subprogram may be all visible in one window on my screen. Of course it may be slower than the alternatives but it’s a pity that it was made obsolescent.

2 Likes
7

My understanding of FORALL is that it is not and was never intended to be a “loop construct” even though the syntax might imply it. I believe it was officially a “indexed parallel array assignment” (the definition used in the “Fortran 95 Handbook”). Granted the differences are probably just a matter of semantics but the fact that compiler developers struggled to get FORALL to deliver the performance of loops sort of backs up the notion that they are not “loops”. I think one of the reasons for DO CONCURRENT is to overcome the confusion about just what FORALL actually does.

1 Like
8

Are there any cases where FORALL cannot be converted to DO CONCURRENT? And if not, why would compilers show a speed difference?

9 
forall (i=2:n)
   a(i) = a(i-1)
end forall

is equivalent to

a(2:n) = a(1:n-1)

but not to

do concurrent (i=2:n)
   a(i) = a(i-1)
end do
10

do concurrent does not support the compact (and DESIRABLE) 1-line “syntactic sugar”:

if (cond) do_something
where (mask) this = that
forall(i=1:5,j=2:18,k=5:7,k<j) a(i,j,k) = elemental_fun(i,j,k)

that is so important to minimize the noise in large codebases.

2 Likes