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

31–40 of 52 posts

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

#31

Post by enriquto »

melan13 wrote: post #30
enriquto wrote: post #16

Earlier quoted context omitted.

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

> 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

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

#32

Post by enriquto »

alexhutcheson wrote: post #23
enriquto wrote: post #16

Earlier quoted context omitted.

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

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

> 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 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.

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

#33

Post by new4thaccount »

atemerev wrote: post #27
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.

Everybody I know in public science (physics) uses gfortran, works just fine.

Good to know, thanks! I've used software compiled with the Intel compiler, but have only written some toy programs in GFortran and it seems fast enough. I like the revival idea behind LFortran though. Reading scientific C++ is much more difficult than Fortran.

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

#34

Post by new4thaccount »

septc wrote: post #29
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.

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).

Thanks!

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

#35

Post by goerz »

jagger27 wrote: post #25
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…

Wouldn't writing an Antlr grammar handle this?

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.

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

#36

Post by alexhutcheson »

enriquto wrote: post #32
alexhutcheson wrote: post #23

Earlier quoted context omitted.

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

> 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 inappropriate for students who want to look at an understandable implementation of the algorithm.

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

#37

Post by enriquto »

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…

> ...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.

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

#38

Post by wahern »

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

Didn't they originate with Fortran?

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

#39

Post by vbarrielle »

enriquto wrote: post #37
alexhutcheson wrote: post #36

Earlier quoted context omitted.

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…

> ...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.

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.

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

#40

Post by jagger27 »

goerz wrote: post #35
jagger27 wrote: post #25

Earlier quoted context omitted.

Wouldn't writing an Antlr grammar handle this?

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/grammars-v4/blob/master/c/C.g4

Post reply on HN