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.
> 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.
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.