[HN Gopher] LFortran: Modern interactive LLVM-based Fortran comp...
___________________________________________________________________
LFortran: Modern interactive LLVM-based Fortran compiler
Author : kergonath
Score : 93 points
Date : 2020-07-02 18:10 UTC (4 hours ago)
(HTM) web link (lfortran.org)
(TXT) w3m dump (lfortran.org)
| sangfroid_bio wrote:
| Looking forward to differentiable programming in Fortran.
| dnautics wrote:
| I believe that's called "Julia".
| ChrisRackauckas wrote:
| There's a library for Julia coming out soon that can
| differentiate Fortran code. So, while tongue and cheek, it's
| not that far off!
| certik wrote:
| That has been requested quite often:
| https://gitlab.com/lfortran/lfortran/-/issues/97
| dng88 wrote:
| Wish 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.
| kergonath wrote:
| To be fair, it does not look much like it was many decades ago.
| mmaul wrote:
| Common Lisp has had Jupyter integration for a while.
|
| First cl-jupyter (https://github.com/fredokun/cl-jupyter) which
| is now in maintance mode and now common-lisp-jupyter
| (https://github.com/yitzchak/common-lisp-jupyter).
|
| Here is a notebook I did awhile back with cl-jupyter:
| https://github.com/mmaul/clml.tutorials/blob/master/CLML-Win...
| fiddlerwoaroof wrote:
| There's this:
|
| https://github.com/yitzchak/common-lisp-jupyter
| waynecochran wrote:
| I 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 assume Fortran, since
| matrices are native types, does this kind of thing even better.
|
| Aside: Fortran 77 was the first programming language I learned in
| 1985 and I hated programming for awhile after that. We called it
| the "F" language. Now that I am a bit older and do a lot of
| linear algebra coding... I wonder if I would like it now.
| adamnemecek wrote:
| You can do this with Julia. Julia has an insanely good interop
| with essentially any language you can name, including cpp and
| Fortran. You will go through julia but hey, for linear algebra
| it's the shit.
| celrod wrote:
| 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) would've
| solved that.
|
| If you want to try external BLAS/LAPACK with Eigen, I'd look
| at: https://eigen.tuxfamily.org/dox/TopicUsingBlasLapack.html
|
| I have `A * B`, `A * B'`, `A' * B` and `A' * B'` small-single-
| threaded-matmul benchmarks here:
| https://chriselrod.github.io/LoopVectorization.jl/latest/exa...
| I compared triple nested loops with Clang, icc, ifort,
| gfortran, Julia, and LoopVectorization.jl with matmul routines
| from ifort, gfortran, OpenBLAS, MKL, and Eigen.
|
| While gfortran's builtin hit over 40 GFLOPS with `A * B` and
| `A' * B'`, it failed to get half that if only one argument was
| transposed. I'm supposed awkward fusing at the start of this
| post because if it had done one after the other, it should have
| still hit >40 GFLOPS when only 1 matrix was transposed.
| kergonath wrote:
| These benchmarks are very interesting! From my experience
| gfortran's MATMUL is very good for small matrices, but
| OpenBLAS gets better from ~10x10 elements. Not quite sure
| that's the same as your benchmark; its colour code is a bit
| confusing. Would you mind making the data available?
|
| Certainly, gfortran's default implementation works well as a
| quick and easy solution for small vectors and matrices
| outside of hot paths. Also, I remember discussions about
| improving matmul(transpose(A),B) somewhat recently. I don't
| remember for which version it was, but it's the sort of
| things that is improved regularly.
|
| I would love an option to align arrays in gfortran. It's very
| important to take advantage of automatic vectorisation but I
| haven't found a reliable way to do it.
| celrod wrote:
| My color coding is bad (and there's an open issue about
| it), but I haven't come up with a great solution. One idea
| I should add was to make everything relative to
| LoopVectorization, but that wouldn't help for those
| interested in other comparisons like Eigen vs gfortran.
|
| I'm on gfortran 10.1.1, so I'd only be missing out on very
| recent improvements (i.e., to trunk).
|
| Note that these benchmarks were dynamically sized. If you
| write a fortran program like real(kind=8),
| dimension(10,10) :: A, B, C ! fill A and B somehow
| C = matmul(A, B)
|
| the compiler will take advantage of the known dimensions
| and inline the call, making it much faster.
|
| > I would love an option to align arrays in gfortran. It's
| very important to take advantage of automatic vectorisation
| but I haven't found a reliable way to do it.
|
| I wish more compilers could also use masks to vectorize
| without padding. If multiplying 7x7 matrices with AVX512,
| the obvious solution is to just mask the loads/stores of
| columns, without the need for padding. Of course, padding
| would also ensure all your loads/stores are aligned, which
| can be nice.
| kergonath wrote:
| I think what the plots need is an option to show or hide
| each curve. It's a rather large increase in complexity
| compared to just generating images, though.
| certik wrote:
| Thanks for the benchmarks. Do you see some intrinsic reason
| why a Fortran compiler couldn't do these optimizations? I
| would think it would know all the information so it would be
| the ideal place to optimize it.
| kergonath wrote:
| If you use LAPACK there's a chance that some Fortran code will
| be run at some point. For example OpenBLAS does it behind the
| scenes of you give it a matrix to diagonalise.
| mhh__ wrote:
| I've never used Eigen, could you explain specifically what lazy
| evaluation implies for this expression? Is it to do with the
| diagonal() call constraining the amount of work to be done?
| waynecochran wrote:
| Yeah, you got it. The diagonal() matrix is not actually
| created since you really don't need all the elements in the
| final computation.
| pantalaimon wrote:
| Is this related to flang?
|
| https://github.com/llvm/llvm-project/tree/master/flang/
| kergonath wrote:
| Not exactly. Development of both started at about the same
| time, but it was a coincidence. Flang is a standard compiler,
| whilst LFortran is more geared towards interactive use a la
| Jupyter, or source-to-source compilation.
|
| Here's a demo of the Jupyter notebook-like interface:
| https://mybinder.org/v2/gl/lfortran%2Fweb%2Flfortran-binder/...
| certik wrote:
| LFortran author here. As kergonath said below, both "new" Flang
| that you linked above, and LFortran started at about the same
| time. I know the Flang developers well and I am hoping we'll be
| able to collaborate in the future more. It looks like MLIR
| would be one option: they are going to use it for Flang and
| LFortran can have a backend that could also use it.
|
| LFortran's main advantage is that it is interactive, so the
| parser and semantics has to be a little different. And also we
| designed it so that it will be quite approachable for people to
| write tools on top.
| baggy_trough wrote:
| Not much of a Fortran yet without arrays, complex numbers, or
| strings.
| dm319 wrote:
| fortran - one of only a handful of languages that natively
| supports multidimensional arrays, maybe the only low level one?
| ironmagma wrote:
| C kind of does, right? A multidimensional array in C isn't
| just an array of pointers.
| certik wrote:
| LFortran author here. We will get there. I spent a lot of time
| in the last year bootstrapping our efforts around
| https://fortran-lang.org/, which was very successful. I have
| shifted my focus on LFortran again now.
| mootzville wrote:
| Nice, I want to play with this, but I see on the Development page
| there is no/limited support for arrays?
| kergonath wrote:
| Not sure about arrays (I am not involved in the project, I just
| thought it was cool). It's still in a very preliminary stage,
| though, so there certainly are rough edges.
| certik wrote:
| LFortran author here. There is a Python prototype version that
| you can see in the notebook and it has very limited support for
| arrays. I stopped spending more time on it once I got further
| enough to validate that the idea works. And I am now spending
| all my time on the production LFortran implementation in C++. I
| am very close to make it usable for some very simple things,
| and then we'll go from there.
| [deleted]
| dang wrote:
| If curious see also
|
| 2019 https://news.ycombinator.com/item?id=19795262
|
| https://news.ycombinator.com/item?id=19788526
| certik wrote:
| LFortran author here. I missed one of these discussions.
| kergonath wrote:
| These are very interesting discussions. I don't know how I
| managed to miss them when I submitted...
| dang wrote:
| The cutoff point for reposts is about a year, so it's good
| that you didn't see them and then not post.
|
| https://news.ycombinator.com/newsfaq.html
___________________________________________________________________
(page generated 2020-07-02 23:00 UTC)