Evaluation of Fortran's SUM(..) without temporary array? - fortran

Question

Readability-wise, I find it preferable to write
momentum = sum( [( calculateMomentum(elements(i)), i=1, size(elements,1) )] )
over
momentum = 0.0d0
do i = 1, size(elements,1)
momentum = momentum + calculateMomentum(elements(i))
end do
because the first version has the form of defining the value of momentum, while the second corresponds to a more lower-level accumulation instruction. The difference becomes more pronounced in real-world code with more arguments and possibly multiple indices.
However, the first version allocates a temporary array. As a human programmer I know, that it could be optimized away, so I was wondering if Fortran offers a syntax, that allows calculating the sum with neither an explicit loop nor a temporary array.
Update
No such construct. It looks like there is no syntax, as what I was asking for. See Vladimir F's answer.
It matters, but less than I thought. I've made my own benchmark (pastebin, embedded) using matrix multiplication using several variants.
C(i,j) = C(i,j) + A(i,k) * B(k,j) was the slowest, probably due to the unnecessary array access in each step.
C(i,j) = sum( [(A(i,k) * B(k,j), k = 1, N)] )` was about 10-20% faster than (1), despite the temporary array.
tmp = tmp + A(i,k) * B(k,j), i.e. using a temporary accumulator variable, was about 20% faster than (2).
C = matmul(A,B) was the fastest by far, compared to (3) by a factor of 25 for 500x500 matrices, growing to 50 for 2000x2000, while the relative speed of the other variants stayed roughly the same.
Bottom line: When the task cannot be expressed in optimized library- or intrinsic functions easily, the sum variant has viable performance, and should only be optimized away, if performance really matters to such a degree in that part of the code.

Answer 1

Whether a temporary array will be allocated or net depends on the optimizations in the compiler. Stack allocation is almost free anyway. Copying the values will probably take longer.
The compiler may optimize unnecessary steps away if it can make sure the result will be the same. However, there is no special syntax for that. Fortran typically tries to stay far from the actual implementation and leaves a lot on the compiler.

Answer 2

For experiment, I've tried this code (which computes the sum of inverse of arr).
program main
use iso_fortran_env, only: dp => real64
implicit none
real(dp) val
real(dp), allocatable :: arr(:)
integer num, loop, i, t1, t2, trate
num = 10**8
arr = [( i, i = 1, num )] !! L1
do loop = 1, 10
call system_clock( t1 )
val = sum( [( testfunc( arr(i) ), i = 1, num )] ) !! L2
call system_clock( t2, trate )
print *, "val = ", val, " in ", (t2 - t1) / real(trate), " (s)"
enddo
contains
function testfunc( x ) result( ret )
real(dp), intent(in) :: x
real(dp) :: ret
ret = 1.0_dp / x
end
end program
Then, on my computer (mac2012), "gfortran-10 -O2 test.f90 && time ./a.out" gives
val = 18.997896413852555 in 1.02999997 (s)
val = 18.997896413852555 in 1.10099995 (s)
val = 18.997896413852555 in 1.17600000 (s)
...
real 0m12.575s
user 0m8.142s
sys 0m4.387s
and "gfortran-10 -O3" gives
val = 18.997896413852555 in 0.875000000 (s)
val = 18.997896413852555 in 0.888000011 (s)
val = 18.997896413852555 in 0.833000004 (s)
...
real 0m9.986s
user 0m5.738s
sys 0m4.210s
In both cases, the htop command shows ~1.5 GB allocated, which may be reasonable if lines L1 and L2 use a temporary array (each ~800 MB with ~0.3 s for allocation).
Because there is no syntax for creating "iterators", I've tried making testfunc() to be elemental (or impure elemental). The only difference here is the lines marked with <--.
program main
use iso_fortran_env, only: dp => real64
implicit none
real(dp) val
real(dp), allocatable :: arr(:)
integer num, loop, i, t1, t2, trate
num = 10**8
arr = [( i, i = 1, num )]
do loop = 1, 10
call system_clock( t1 )
val = sum( testfunc( arr ) ) !<--
call system_clock( t2, trate )
print *, "val = ", val, " in ", (t2 - t1) / real(trate), " (s)"
enddo
contains
impure elemental & !<--
function testfunc( x ) result( ret )
real(dp), intent(in) :: x
real(dp) :: ret
ret = 1.0_dp / x
end
end program
Then, "gfortran-10 -O2" gives
val = 18.997896413852555 in 0.437000006 (s)
val = 18.997896413852555 in 0.453999996 (s)
val = 18.997896413852555 in 0.437999994 (s)
...
real 0m5.946s
user 0m5.069s
sys 0m0.842s
and "gfortran-10 -O3" gives
val = 18.997896413852555 in 0.225999996 (s)
val = 18.997896413852555 in 0.252000004 (s)
val = 18.997896413852555 in 0.246999994 (s)
...
real 0m3.909s
user 0m3.009s
sys 0m0.867s
The htop command show ~800 MB, so it seems only arr is allocated.
For comparison, the following code calculates val with an explicit do-loop (using a scalar version of testfunc())
val = 0
do i = 1, num
val = val + testfunc( arr(i) )
enddo
which gave the same timing with the second code with elemental + testfunc(arr) above (on my mac).
In all the above code, the -Ofast option resulted in a runtime error (Illegal instruction). But this was due to the line L1 (arr = [( i, i = 1, num )]). If I allocate arr beforehand and populate it with an explicit loop, -Ofast also worked without problem (giving almost the same timing with -O3 in this case).

Answer 3

If you make calculateMomentum and elemental function, then it can be used for both scalar values and for arrays
for example with:
elemental function calculateMomentum(obj, v) result(p)
class(body), intent(in) :: obj
real, intent(in) :: v
real :: p
p = obj%mass * v
end function
you can apply the above to an array of v
integer::i
type(body) :: ball
real, allocatable :: v(:), p(:)
real :: tot_p
allocate(v(10))
v = [ (10+i, i=1, 10) ]
p = calculateMomentum(ball, v)
tot_p = sum(p)
having an intermediate array to hold the values is advantageous because it keeps the data close by (probably within the cache-line) and the sum() function would be as quick as it can be.
imagine the type body as follows for example
type body
real :: mass
end type