
Creating LFortran, an interactive Fortran compiler built on top of LLVM - bauta-steen
https://lfortran.org/blog/2019/04/why-we-created-lfortran/
======
archgoon
There seems to be a missing question in the FAQ: Why is Fortran worth saving?
What are the advantages of writing code in Fortran? Why not just allow the
ports to C++ to happen?

There might well be good answers to these; but it seems that if you want to
make Fortran cool again, you have to provide a vision for what makes it
special.

~~~
enriquto
> Why not just allow the ports to C++ to happen?

I see two reasons why C++ is not a suitable language for domain specialists in
numerical computing.

1\. Programming in C++ requires a certain discipline to understand what is
going on, for example to not accidentally make useless copies of huge arrays.
In fortran you do not need to learn such a discipline because everything is
explicit.

2\. Fortran natively supports multidimensional numeric arrays. In C++, not
really; you need to use "libraries" whose evolution is independent to that of
the language and may become unsupported. A few years ago, everybody said to
use "blitz", somewhat later it was "eigen", now it probably is something new.
The C++ numerical code that you may write today will probably be obsolete in a
few decades. Yet the fortran code will be alright. It is "eternal".

~~~
alexhutcheson
Eigen is still the best-in-class C++ library for linear algebra as far as I
know. It's been around for a while, is still actively developed, and I don't
think there's a risk of it becoming obsolete anytime soon.

That being said, the learning curve for someone not familiar with C++ to write
code using Eigen is much higher than writing the same code in Fortran. If
you're not already a C++ programmer, you just want to do some math, and
Numpy/Matlab are too slow or constrained, then Fortran is a solid choice.

~~~
enriquto
> That being said, the learning curve for someone not familiar with C++ to
> write code using Eigen is much higher than writing the same code in Fortran.

Moreover, the algorithms implemented inside eigen are hidden behind dozens of
onion-like layers. Once you peel all these layers you find code such as this:

[https://eigen.tuxfamily.org/dox/JacobiSVD_8h_source.html](https://eigen.tuxfamily.org/dox/JacobiSVD_8h_source.html)

I can read and write C++ and I teach numerical linear algebra for a living,
but mother of god, this SVD implementation is horrendously unreadable to me.
Most of the lines of code are stupid bureaucracy necessary just to add and
multiply a few vectors. The same algorithm in linear algebra textbooks
requires about fifteen lines of pseudo-code, and similarly for a fortran
implementation.

~~~
alexhutcheson
Yeah, libraries that make extensive use of templates are basically dark magic
only comprehensible to C++ experts (see also: almost everything in Boost).

The positive side of this is that it enables nice interfaces for the library,
and makes a lot of the abstractions basically "free" (since the cost is paid
at compile time rather than via pointer indirection at runtime). But it
definitely makes those libraries inappropriate for students who want to look
at an understandable implementation of the algorithm.

~~~
enriquto
> ...makes a lot of the abstractions basically "free"

Maybe it is just me, but I do not really see the need for "abstractions" in a
linear algebra library. Numbers are already an abstraction, you do not want to
hide them! Ok, maybe you want to choose between "float" and "double", but this
does not merit all that overcomplication.

~~~
vbarrielle
The abstractions inside Eigen are there to enable powerful compile time
optimisations, such as compiling the addition of three vectors
`Eigen::VectorXf x = a + b + c;` in a single loop instead of naively
allocating a temporary to evaluate `Eigen::VectorXf tmp = b + c;` then
evaluating `Eigen::VectorXf x = a + tmp;`.

This logic is omnipresent in Eigen and is crucial to its performance. It is
also used to have specialized versions of some decompositions when the
matrix's size is known at compile time.

------
goerz
This looks very interesting! I hope that maybe this project can include a
“refactoring parser”, that is, for each token in the parse tree, store where
in the source code file that token originated from. Also, white space and
comments have would have to be included, such that the round trip (source file
-> AST -> source file) is possible without loss. I’ve long wanted to write
some refactoring tools for modern Fortran, but not having such a parser is a
big blocker—there’s only so much you can do with regexes.

~~~
jagger27
Wouldn't writing an Antlr grammar handle this?

~~~
goerz
Does Antlr support an annotated parse tree that would allow for round-
tripping? I didn't see anything in the documentation, at a quick glance. Even
then, formulating a grammar (especially one that also catches whitespace and
comments) seems like a pretty daunting task.

~~~
jagger27
Catching whitespace and comments is no problem in Antlr[1]. I'm not exactly
sure what you mean by round-tripping. In terms of how daunting it is, it's
much easier than trying to use Flex/Bison or lex/yacc, that's for sure.

1: At the bottom of the grammar, there are rules to intentionally skip over
whitespace and comments, but it could have just as easily captured them and
parsed them further.
[https://github.com/antlr/grammars-v4/blob/master/c/C.g4](https://github.com/antlr/grammars-v4/blob/master/c/C.g4)

~~~
goerz
What I mean by "round-tripping" is that I would have to be able to read a .f90
file into an AST structure, then write out the tree to a new file, and end up
with the exact same file content as the original. This would be a prerequisite
for a refactoring tool, which has to preserve comments and code formatting.

------
betatim
You can try it online: [https://mybinder.org/v2/gl/lfortran%2Fweb%2Flfortran-
binder/...](https://mybinder.org/v2/gl/lfortran%2Fweb%2Flfortran-
binder/master?filepath=Demo.ipynb) !

------
ktpsns
Using Fortran in Jupyter CNA be extremely handy to learn certain algorithms by
interactive exploration. Despite all the nice and modern alternatives, Fortran
is so popular in HPC world that still generations of students will have to
learn it.

------
ben_e
This post talks a lot about creating a community. Are they doing that anywhere
in particular?

~~~
certik
I am one of LFortran authors. We just open sourced it recently. Do you have
any recommendations if we should create a mailinglist, or rather use something
like Discourse? Or both.

Right now if you have any questions, you can open an issue at our GitLab
repository:

[https://gitlab.com/lfortran/lfortran](https://gitlab.com/lfortran/lfortran)

------
new4thaccount
Question:

What is a good Fortran compiler/implementation these days?

I know they have Intel and IBM and SimplyFortran as commercial software.
GFortran works via GCC. Is it as good? Has anyone on here used this LFortran.

~~~
septc
Gfortran is very nice, but I recommend a recent version (at least ver >= 7)
rather than old versions (e.g. ver 4.4, which may still be the default on
CentOS 6 etc). For performance, I guess Intel fortran is probably better (but
also depends on calculations).

~~~
new4thaccount
Thanks!

------
C1sc0cat
Not sure what they mean by lack of support for GPU - Intel Fortan has this and
I am sure others do.

~~~
certik
I am one of the LFortran authors.

Can you please point me to some documentation or examples where Intel Fortran
is used to offload to, say, NVIDIA GPUs? I don't think it supports it yet.

PGI and IBM support CUDA Fortran, other compilers don't. PGI/Flang has an
experimental support for offloading "do concurrent". Some compilers also
support the openmp/openacc pragmas and GPU offloading. One can also call CUDA
C from any Fortran compiler via iso_c_binding. None of this is ideal.

I think it's still a research problem how to best integrate GPU support in the
language itself. CUDA Fortran is nice --- one thing we want to do down the
road is to implement CUDA Fortran and to allow LFortran to transform code it
understands into a Fortran dialect that all Fortran compilers can compile, so
that one can use any Fortran compiler and still use CUDA Fortran.

The other path is to parallelize "do concurrent", but part of this is also
means to extend Fortran to allow to specify the array layout, as Kokkos
([https://github.com/kokkos/kokkos](https://github.com/kokkos/kokkos)) allows.

That is one of the biggest problem with Fortran: people want to be assured
that their code will run on modern hardware. When using, e.g., C++ and Kokkos,
then there is some assurance that the code will run.

~~~
xiphias2
AFAIK Julia uses patched LLVM's PTX output, which I think should be done by
all languages to work towards a common optimization platform. Also CuArrays
uses multiple higher level NVIDIA libraries, like CudaBLAS and CuDNN.

The goals look similar to me, so it's worth to take a look at them.

~~~
certik
Yes, I was planning to start with what NumBa
([http://numba.pydata.org/](http://numba.pydata.org/)) is doing, they also use
the LLVM PTX backend.

There is a really promising new project by Chris Lattner (the original author
of LLVM) called MLIR:
[https://github.com/tensorflow/mlir](https://github.com/tensorflow/mlir). That
might be the best intermediate representation that all the compilers (Julia,
Fortran, ...) could target.

