Hacker News new | ask | show | jobs
by jdw64 26 days ago
I think the OP's thoughts are really deep, but I disagree on some points.Personally, I think the suggestion in the OP about switching Fortran to row-major is a separate issue. I have doubts about whether scientific languages should make such a switch. Rather, I consider it Fortran's competitive advantage. You can directly bring mathematical thinking into it. There are also cache related concerns.

Because it's an array oriented language, I think the need for a tracing GC is relatively low. The advantage of GC comes into play when object graphs are complex, but looking at old Fortran code, arrays mostly operate outside that domain.

In reality, the biggest problem is that Python has become too mainstream, and hardware performance has improved too much. Old numerical computation books were mostly in Fortran, but now they're in Python. The reason is simpler than you might think. Python has a strong ecosystem for visualization packages. Beyond just interfacing with Fortran, Python is more powerful as a working environment. And most scientists, who prioritize building their careers around papers with smaller scale computations rather than large scale Fortran dominated calculations requiring massive equipment, have gravitated toward Python, which lets them quickly sketch ideas.

And realistically, Python's greatest strength is that while it's inadequate in almost every area, it can do almost everything. I think that's the most important factor in language choice. Once you learn Python, you can do EDA, ETL, numerical computation, build websites, create apps with Qt, and much more. There are performance bottlenecks due to the GIL, but most tasks don't actually require that level of performance.

Fortran can push hardware to its limits when used well, but as such hardware intensive tasks increasingly shift toward large scale collaborative work, I think it's been losing its competitive edge.

It's not that Fortran is bad, but realistically, being able to do many things matters more. Before Python became widely used, programming books had too many languages for each domain. Math had Maple, and so on. But Python, honestly, just works because you can do a lot with it if you're willing to sacrifice a bit of performance. Many people say 'performance is important,' but I question whether there are really that many tasks where performance matters that much

p.s This is my post about the difference between row-major and column-major order.(https://www.makonea.com/en-US/blog/why-c-family-nested-for-l...)

1 comments

I agree with the explanation you give at that link.

For linear algebra, the Fortran convention, "column-major" is indeed superior.

This is most obvious when computing a matrix-vector product, i.e. a linear transformation of a vector, which is a very common operation.

In schools this operation is typically taught in the wrong way, i.e. by computing scalar products of row vectors from the matrix with the column vector operand.

This naive method is inefficient. The correct method that must be used in computers is to avoid scalar products, but use the so-called AXPY operation (from its BLAS name. i.e. scalar A times vector X Plus vector Y), where the operands are column vectors from the matrix and the column vector that is the second operand of the matrix-vector product.

Therefore, to compute the product one needs to read columns from the matrix, so for maximum throughput the elements of a column must be stored sequentially.

In schools, also the matrix-matrix product is taught in the wrong way, with scalar products between row vectors and column vectors.

The correct way also avoids the inefficient scalar products and replaces them with tensor products of column vectors.

hank you for your response. I didn't know there was a pattern called AXPY. I was vaguely aware that something like that was used, but I didn't know it was called AXPY. Thanks to you, I've learned a new term. I'll save this for myself as well. Thank you for the kind explanation