Re:Fortran
by galangalalgol on Monday August 28, 2023 @07:18AM
(#37292377)
BLAS/LAPACK are written in fortran was the point I think. There are eigen and nalgebra certainly, but neither exports as cleanly to python, and neither is significantly (if at all) faster.
CuBLAS on the other hand makes a lot of sense to use from python if you have the right hardware.
The reference implementation of BLAS that you should absolutely not use is written in Fortran. The actual implementations are written in C/C++/ASM.
That's not to say you should use C yourself, memory management is a lot nicer in Fortran, for multidimensional arrays. You can stack allocate arrays inside functions and modern fortran has move semantics. Arrays are contiguous even if they have multiple index. It's generally a nice language for math, has good C API integration (both as caller and callee) and compiles down to small libraries without runtimes.
Re:Fortran
by galangalalgol on Monday August 28, 2023 @09:17AM
(#37293471)
Thanks! I did not most any of that. Except for that it is good at math.
Loops in Python are excruciatingly slow, for no reason. Some algorithms are naturally written using loops, and Python makes this very uncomfortable, forcing you to rewrite your algorithm in a non-natural way. I hate writing numerical code in Python due to that; it just feels uncomfortable.
For scientific computation I just need multi-dimensional arrays of floats and fast loops. Fortran has both of these things natively. Python has neither.
I prefer vector types for this kind of stuff, as they are more compact than loops and naturally lend themselves to auto-vectorisation. In the end it comes down to the programming style preference.
A lot of the code used in scientific computing cannot be vectorized because the latter loop is dependent on the former loop (like time stepping in a simulation). It’s not really a programming style preference.
C++ and Rust don’t really have good semantics for scientific computing (linear algebra). They’re great for many other domains like “system’s programming”, where Fortran doesn’t compete, of course. The only language that’s similarly (in fact, more) expressive as Fortran for scientific computing today, as well as holding up for performance, is Julia
R or Python are still much easier to use and give you the same access to high-performance numerical accelerators via BLAS/LAPACK backends. And if you need a low-level language (e.g when developing an optimised routine that solves a specific problem), I would use a high-performance widely supported systems programming language like C++ or Rust.
Fortran seems to be around mostly for legacy reasons. And I am not sure that legacy considerations alone make a good foundation.