Hacker News Reader

Comment by oconnor663 | Hacker News Reader

> The benchmarks where Fortran is much slower than C/C++ involve processes where most of the time is spent reading and writing data, for which Fortran is known to be slow.

Why would IO be slow in any language? What does the language have to do besides buffering and system calls?

> In Fortran, variables are usually passed by reference, not by value. Under the hood the Fortran compiler automatically optimizes the passing so as to be most efficient.

Aren't arrays implicitly passed by reference in C also?

View on HN

>Why would IO be slow in any language?

I believe many Fortran implementations default to unbuffered io.

Which is probably easy enough to change.

But I think that's really the core issue. Physicists don't want to learn more about programming languages. They want whatever mostly works out of the box and has local documentation and expertise specific to their problem domain.

>Aren't arrays implicitly passed by reference in C also?

He covers that. C passes arrays by reference, but the individual elements aren't contiguous. He says Fortran passes an optimized reference.

Unless you're passing arrays of pointers to things about, the individual elements in a C array should be contiguous.

>Unless you're passing arrays of pointers

That seems to be the context from his example:

  for(i = 0; i < nrows; i++){
     array[i] = malloc(ncolumns * sizeof(double));
  }

I suppose the counterpoint is that he's doing it wrong. But again, maybe physicists just don't want a tool with that much flexibility.

I was taught to do it like this in C:

  double *a = malloc(sizeof(double)*nx*ny*nz);
  int id;
  for(int k = 0; k < nz; k++) {
      for(int j = 0; j < ny; j++) {
          for(int i = 0; < i < nx; i++) {
              id = k*nx*ny + j*nx + i;
              a[id] = /* some mathematical operation */
          }
      }
  }

You can do it in other ways (arrays of pointes, etc), but I think this is probably the simplest conceptually, and the memory is contiguous.

he's definitely doing it wrong there. As a scientific C programmer, I would never do that, I would malloc one contiguous array of nrows*ncolumns. And my freeing of the array would be as simple as his Fortran deallocate.

Sure, C could make multi-dimensional array handling nicer, but I have macros that basically do his A[x,y,z] for me, admittedly a bit more verbosely.

Many of his points about Fortran are true, but almost all his statements about C are false. Or nearly so, yes, copying an array of floats requires calling a function, memcpy, and not just using an equals sign, but that ain't rough and falls into his idea of "what actually happens ‘under the hood’ inside a computer". And others are easily handled by adopting things like the MKL (want to take the sin of everything in an array, see https://software.intel.com/en-us/mkl-developer-reference-c-t... )

Fair enough then, I suppose that in C you have to do something like that if you want both that your matrix size is decidable at runtime, and to be able to index it with m[x][y] rather than some function.

That’s not strictly true. You can malloc an m*n sized array and then assign to another array the pointer to the head of each column, allowing you standard style indexing.

If you do that, every access will actually dereference that pointer and won't be able to optimize the standard style indexing to a multiplication and addition, so this still carries a significant performance cost.

You can always use a macro (or inline function, if the array is a rich wrapper type):

  arr(m, x, y)

Not quite as nice, but not too bad.

Reply on news.ycombinator.com