I was not bringing up vectorization in Fortran. E.g., in Fortran we can have

     Real X(20, 30,40), all

     Call addall(X, 20, 30,40, all)

and have

          Subroutine Addall (Z, L, M, N, Result)

          Real Z(L, M, N), All, Result

          Integer L, M, N, I, J, K

          Sum = 0.0
          Do 100 I = 1, L
          Do 100 J = 1, M
          Do 100 J = 1, N
          All = All + Z(I, J, K)
     100  Continue

So what is good here is that in the subroutine the parameter Z gets its array bounds PASSED from the calling routine, the statement

     Real Z(L, M, N)

honors those bounds, and the code then does the indexing arithmetic (row major or column major, I don't recall which) using the bounds passed as arguments to the parameters L, M, N. That is, in the subroutine we can have the array bounds as parameters, and still Fortran does the array indexing arithmetic.

Can't do that in C: In C the programmer has to do array indexing with their own code in the subroutine. Thus to the compiler this code is just ordinary code and has to be treated as such. In contrast array indexing Fortran does is not from ordinary code thus permitting Fortran to make better use of registers and, for example, leaving intermediate values in registers and not writing them back to storage in variables known to the source code.

Here vectorization has nothing to do with it.

Bluntly, C doesn't support arrays, and that's a bummer for the programmer and also execution speed.

My point is on topic because this thread is about C performance, and I've brought up the point that functionality, in this case array indexing arithmetic, defined in the language and implemented in the compiler can be faster than the programmer implementing the functionality in their own code, especially, in the case of strings, if that implementation is via external routines.

I thought that this was all simple and clear.

> leaving intermediate values in registers and not writing them back to storage in variables known to the source code

C compilers (with optimization on) don't spill intermediates either.

Your decades of experience are appreciated, but apparently your decades of experience don't cover looking at what optimizing C compilers learned to do in the last 30 years or so.

> Bluntly, C doesn't support arrays, and that's a bummer for the programmer

That's true.

> and also execution speed.

That isn't, or at least you haven't demonstrated it.

Arrays are vectors.