Automatic object of parameterized derived type

Help
26

I just created an example on Godbolt (Compiler Explorer) to compare the assembly generated for adding arrays of derived types vs a real array:

  integer, parameter :: n = 10
  type(foo) :: a(n), b(n), c(n), d(n)       ! derived type
  type(real) :: aa(n), bb(n), cc(n), dd(n)  ! intrinsic type

  ! ... fill values ...

  d = a + b + c
  dd = aa + bb + cc

For the intrinsic reals, gfortran generates the assembly

        mov     edx, 1
        jmp     .L20
.L37:
        lea     rax, [rdx-1]
        movss   xmm0, DWORD PTR [rsp+960+rax*4]
        addss   xmm0, DWORD PTR [rsp+832+rax*4]
        addss   xmm0, DWORD PTR [rsp+704+rax*4]
        movss   DWORD PTR [rsp+576+rax*4], xmm0
        add     rdx, 1
.L20:
        cmp     rdx, 10
        jle     .L37

One can recognize the loop check in .L20, and the two add operations.

For the derived type, the assembly is

        mov     ebx, 1
        jmp     .L19
.L36:
        lea     r12, [rbx-1]
        lea     rbp, [0+r12*8]
        lea     rsi, [rsp+880+rbp]
        lea     rdi, [rsp+1008+rbp]
        call    __testfoo_MOD_foo_add
        mov     QWORD PTR [rsp+1096], rax
        lea     rsi, [rsp+752+rbp]
        lea     rdi, [rsp+1096]
        call    __testfoo_MOD_foo_add
        mov     QWORD PTR [rsp+624+r12*8], rax
        add     rbx, 1
.L19:
        cmp     rbx, 10
        jle     .L36

Again the loop and two add operations are recognizable, meaning the array operations have been rewritten in a manner consistent with the loop code:

do i = 1, 10
  d(i) = (a(i) + b(i)) + c(i)
end do

No need for engineers and scientists to fuss around with expression templates and meta-programming, unless they want precise control over the generated code. This reminds me of some historical threads a NASA report from the time when Fortran compilers did not yet fully support multidimensional arrays (in terms of quality of the generated machine instructions). Apparently, many some engineers wrote their own linear algebra routines with matrices stored as vectors.

Edit: I’ve edited the last paragraph for accuracy

4 Likes
28

I recently contacted the lead proposer of Linear Algebra support in C++. His name is Bob Stegall. He says it may not come up till C++26.
We have a lot of time to improve !!!

29

Here’s a snapshot taken from the report by McGee, L. A., & Schmidt, S. F. (1985). Discovery of the Kalman filter as a practical tool for aerospace and industry (towards bottom of page 3)

image
image1386×532 91 KB

The authors are referring to work performed in 1959-1960. The purpose of the work was feasibility studies on midcourse navigation and guidance for a manned lunar mission (Apollo program).

1 Like
30

Correctly said. I too feel many times that trying to implement all the C++ features in Fortran is a waste of time. Engineers and scientists don’t need all of them. I see many times somebody comes and posts “this feature is there in C++ and Fortran should also have it”. I think we are more and more trying to become C++ in the guise of Fortran. That’s not good. Let us think independently and come up with good practices in Fortran. Then new paradigms may evolve from that. If all that Fortran is doing is to copy C++ with Fortran syntax then why learn Fortran. We can learn C++ itself. Of course some good features we can adopt but more and more trying to imitate C++ is not good.

2 Likes
31

This does kind of make me wonder if they had inadvertently swapped the order of the loops and were accessing the arrays non-contiguously (assuming things worked like this on the IBM 704), or the problem was really in the generated machine instructions.