6 ms·

This is a great comment, but it's in the wrong place. The OP is about using Rust/C to compose network and packet handling software; using Fortran there would be

This is a great comment, but it's in the wrong place. The OP is about using Rust/C to compose network and packet handling software; using Fortran there would be completely pointless. There is no easy gain to be found from vectorization in networking.

graycat 7y ago
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.
- tom_mellior 7y ago
  > 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.
- eigenloss 7y ago
  Arrays are vectors.

graycat 7y ago

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.

tom_mellior 7y ago
> 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.
eigenloss 7y ago
Arrays are vectors.