[deleted]
LFortran: Modern interactive LLVM-based Fortran compiler
41–50 of 73 posts
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#42Wish lisp have these like jupyter integration. And my first computer lecture many decades ago is really about how he hated fortran and why FORTRAN is still not dead (Mainly negative view due to haveGOTO that time). And it is still not dead.
Lisps were at the genesis of the original concept, it was called Lisp Machine, and the experience can still be replicated when using commercial Common Lisps like Allegro.
Fortran has been continuously updated, supports OOP, modules, and even generics.
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#43Earlier quoted context omitted.
fortran - one of only a handful of languages that natively supports multidimensional arrays, maybe the only low level one?
That's ridiculous, you can make a C++ class and overload operator() like Eigen to easily make a multi-dimensional array.
By that reasoning, all turing-complete languages support multi-dimensional arrays.
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#44Not much of a Fortran yet without arrays, complex numbers, or strings.
> Not much of a Fortran yet without arrays, complex numbers, or strings.
A fortran without strings would still be a fortran, for many people. In fact, it could arguably be "a better fortran". Without complex numbers or arrays, not at all.
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#45I use C++ Eigen extensively. I wonder if it feasible to write a C++ programs that hands off blocks of linear algebra code to Fortran subroutines. Eigen does a wonderful job of late binding and lazy evaluation so that something like the following is fairly efficient: (L.transpose() * P).diagonal().array().square().mean(); which computes the squared average of column by column dot products between matrices L and P. I a…
I think Eigen's template strategy is probably hard to beat from the perspective of combining operations. How well Fortran does is probably mostly up to the compiler implementation. In some of my benchmarks, gfortran sometimes seems to fuse the operations and end up much slower than if it has performed them separately in succession, but I wouldn't be surprised if compiling with `-fexternal-blas` (and linking MKL) woul…
If you have a look at the different fortran implementations of BLAS gemm (matrix multiplication), you'll see that the transposed matrix cases are treated specifically. In fact, IIRC, the gemm function has flags to indicate for each matrix if it is transposed.
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#46Wish lisp have these like jupyter integration. And my first computer lecture many decades ago is really about how he hated fortran and why FORTRAN is still not dead (Mainly negative view due to haveGOTO that time). And it is still not dead.
Lisps were at the genesis of the original concept, it was called Lisp Machine, and the experience can still be replicated when using commercial Common Lisps like Allegro. Fortran has been continuously updated, supports OOP, modules, and even generics.
Sadly, AFAIK, BLAS hasn't been updated to use generics. It would be so nice to have support for integer vector/matrix operations in there (not that it would require generics to have that, but it could be easier to implement integer support with it, though I suspect that for efficiency reason it might not be used in the end).
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#47Support for arm?
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#48Modern fortran is surpisingly pleasant to write.
The last time optimisation came up, I tried the author's problem - multiplying two 4096x4096 matrices - in numpy, FORTRAN and Rust, on a standard laptop. Supposedly it took 9 hours in naive Python (I didn't try). Results were:
Python3 (numpy 1.18.4) 1.3s FORTRAN (gfortran 9.3.0) 6.0s Rust (1.43.1, debug) >60s Rust (1.43.1, release) 4.0s
What surprised me is that python and fortran solutions were written in minutes. The Rust solution took hours and multiple forum posts for help. There's no obvious way, and every single way I tried had "gotchas" and utterly astonishing behaviour in it, particularly with simple, statically-allocated arrays.
Fortran could do with proper namespaces, and properly dropping some of its older conventions, though. Reading it feels like archaeology.
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#49Not much of a Fortran yet without arrays, complex numbers, or strings.
fortran - one of only a handful of languages that natively supports multidimensional arrays, maybe the only low level one?
Not a low-level one but the CLR natively supports multidimensional arrays although I don't think they are exposed to C#.
I've written some F# code and for some trivial cases I was benchmarking there was some interesting performance differences between a native multi-dimensional array and an array-of-arrays version.
It wasn't important enough to look into so I don't know if the difference is due to quirks of the CLRs implementation or due to memory access patterns.
Re: LFortran: Modern interactive LLVM-based Fortran compiler
#50I use C++ Eigen extensively. I wonder if it feasible to write a C++ programs that hands off blocks of linear algebra code to Fortran subroutines. Eigen does a wonderful job of late binding and lazy evaluation so that something like the following is fairly efficient: (L.transpose() * P).diagonal().array().square().mean(); which computes the squared average of column by column dot products between matrices L and P. I a…
You can define EIGEN_USE_BLAS and then Eigen will delegate matrix operations to BLAS routines (such as gemm) instead of its own engine [0]. Then, you could link your program to a BLAS implementation written in Fortran.
However, when I last researched this for my previous work, OpenBLAS was the fastest open source implementation and is written in a mix of C and assembly, not Fortran. The repository contains quite a lot of Fortran, but it is mostly for the LAPACK implementation, which is not part of BLAS.
In our testing we got a nice speedup of our signal processing pipeline when enabling EIGEN_USE_BLAS, but this was on ARM64, so your experience may differ.
[0] https://eigen.tuxfamily.org/dox/TopicUsingBlasLapack.html