Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Creating LFortran, an interactive Fortran compiler built on top of LLVM

lfortran.org

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#41

Post by xiphias2 »

certik wrote: post #18
C1sc0cat wrote: post #10

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

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 a…

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.

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#42

Post by melan13 »

enriquto wrote: post #31
melan13 wrote: post #30

Earlier quoted context omitted.

> I see two reasons why C++ is not a suitable language for domain specialists in numerical computing. Have you heard of MPI or even OpenMP ?. They can be used to accelerate fast computation in C++ or even work on domain-specified parallel execution.

> Have you heard of MPI or even OpenMP ?. They can be used to accelerate fast computation in C++ these features are also available in fortran since forever

> Hence why learning Fortran ?

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#43

Post by goerz »

jagger27 wrote: post #40
goerz wrote: post #35

Earlier quoted context omitted.

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.

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…

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.

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#44

Post by certik »

xiphias2 wrote: post #41
certik wrote: post #18

Earlier quoted context omitted.

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 a…

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.

Yes, I was planning to start with what NumBa (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. That might be the best intermediate representation that all the compilers (Julia, Fortran, ...) could target.

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#45

Post by certik »

C1sc0cat wrote: post #22
certik wrote: post #18

Earlier quoted context omitted.

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 a…

Ah I sit corrected I though Intel would it looks like they have their own ideas in that area.

No worries. Yes, ultimately down the road in couple years, if there is some agreed upon way of extending Fortran to handle GPU well, the best way is to get it into the Fortran standard itself, that way all compilers will eventually support it. I recently became the Fortran Standard Committee member, so when the time is right, I will try to help on this front. Right now it's too early, first we need to implement the new capabilities in some compilers and get some experience and agreement among users. My own first goal is to get LFortran polished enough to get first users.

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#46

Post by certik »

new4thaccount wrote: post #26

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.

The best open source implementation is GFortran. Just make sure you use a recent version, as others mentioned.

Regarding commercial implementations, I only have experience with Intel and NAG, both of which are very good.

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#47

Post by WalterGR »

acqq wrote: post #5
archgoon wrote: post #3

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.

Recently: https://news.ycombinator.com/item?id=19705561#19706731

That link is to a comment on the post

The new features of Fortran 2018 [pdf]

https://news.ycombinator.com/item?id=19705561

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#48

Post by certik »

goerz wrote: post #24

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…

One of LFortran authors here. Yes, we already have an open issue for exactly this: https://gitlab.com/lfortran/lfortran/issues/42. As you can read there, it's actually not that easy as I first thought. But I think it's very much worth pursuing.

For example, Python's AST is not round-trippable, and that forces people to write alternative parsers such as Parso (https://github.com/davidhalter/parso).

ANTLR should allow to parse all the white space. But the issue is how to represent it in the AST, see the issue for more details. One could have an AST and a parser just for this round-trippable application, but that defeats the purpose. The goal should be to have this part of the compiler so that one can trust that it parses things correctly.

Right now I am concentrating my efforts to finish gfortran compatibility (see the roadmap at https://lfortran.org) and to get first users. Once we get further along, we will tackle this problem. I am hopeful there might be a way to do this.

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#49

Post by simonbyrne »

endoftime5 wrote: post #14
zorked wrote: post #9

Earlier quoted context omitted.

Where does the Modern Fortran community congregate? Any websites or mailing lists?

Quite a healthy community on github producing nice modern Fortran code! https://github.com/Fortran-FOSS-Programmers

Am I missing something? Other than the doc generator (which is in Python), none of the repos have been touched for a year or so.

Re: Creating LFortran, an interactive Fortran compiler built on top of LLVM

#50

Post by certik »

alexhutcheson wrote: post #36
enriquto wrote: post #32

Earlier quoted context omitted.

> 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 I can read and write C++ and I teach numerical linear a…

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 inappro…

The main advantage of this approach is that you can use any C++ compiler and the library (in this case Eigen) will work. The disadvantage of this approach is that the code is incomprehensible to average scientists, you must spend a lot of effort to become a C++ expert.

The advantage of Fortran is that the code is simple and comprehensible to average scientist, and yet fast, because the effort goes into the compiler itself. I would also argue it is easier to implement an optimization pass in the compiler than implement optimizations on the template level in C++. The disadvantage is that you need a good Fortran compiler. If your compiler can't run your code on, say, GPU, then suddenly there is not a good path forward. While in C++, there is always a way forward via template metaprogramming: perhaps ugly, but at least it gets the job done.

Post reply on HN