Author of LFortran here. LFortran is written in C++, because I knew I will be able to fully deliver the project in it. So I know C++ and Fortran very well. I can say for sure that C++ is not superior in every way. It's slower to compile, hard to deal with dependencies (that's more of a tooling issue), it's more complex, and specifically for numerical array-oriented computing C++ is actually much more verbose and harder to read. For non-numerical computing, such as compiler development, C++ is not a bad choice, that's why I chose it. The slow compilation of C++ is truly a major problem for me, and after we deliver LFortran we'll see if maybe moving to C might be worth it, just to get 10x faster compilation of the C/C++ sources of LFortran itself (the speed of LFortran I think would be similar, we already use arenas and other tricks for performance, which can be done in C just as easily).
I haven't used vcpkg, but looking at their tutorial at https://learn.microsoft.com/en-us/vcpkg/get_started/get-star..., it seems you still have to use cmake, and if so, it is indeed more complex than fpm (https://fpm.fortran-lang.org/tutorial/hello-fpm.html) where you don't use cmake. Fpm is similar to Cargo. Cargo is indeed as simple as fpm. However, as I mentioned above, this is just a tooling issue, somebody can (and should!) write Cargo for C++. In fact, fpm can build C++ projects also.
The best package manager that I like the most for C++ is Pixi (https://pixi.prefix.dev), that works really well.
Author of the blog post. It's just being a non-native speaker and writing the blog post by hand shows these little mistakes. I've been using the terms "code" and "codes", but you might very well be right that my usage is not entirely correct. I'll ask native speakers what the proper usage is here.
It's very common among scientific programmers to call programs "codes," native speaker or not. It's just a quirk of different computing communities evolving differently.
Author of LFortran here. The historical answer is that both LFortran and Flang started the same year, possibly the very same month (November 2017), and for a while we didn't know about each other. After that both teams looked at the other compiler and didn't think it could do what they wanted, so continued on their current endeavor. We tried to collaborate on several fronts, but it's hard in practice, because the compiler internals are different.
I can only talk about my own motivation to continue developing and delivering LFortran. Flang is great, but on its own I do not think it will be enough to fix Fortran. What I want as a user is a compiler that is fast to compile itself (under 30s for LFortran on my Apple M4, and even that is at least 10x too long for me, but we would need to switch from C++ to C, which we might later), that is very easy to contribute to, that can compile Fortran codes as fast as possible (LLVM is unfortunately the bottleneck here, so we are also developing a custom backend that does not use LLVM that is 10x faster), that has good runtime performance (LLVM is great here), that can be interactive (runs in Jupyter notebooks), that creates lean (small) binaries, that fully runs in the browser (both the compiler and the generated code), that has various extensions that users have been asking for, etc. The list is long.
Finally, I have not seen Fortran users complaining that there is more than one compiler. On the contrary, everybody seems very excited that they will soon have several independent high-quality open source compilers. I think it is essential for a healthy language ecosystem to have many good compilers.
I appreciate the usecase you're describing but I feel like "that has good runtime performance (LLVM is great here)" is at odds with the rest of that list. I don't see that as a problem though. I think it's useful to have a very fast lightweight compiler for development and prototyping (both of projects and the compiler itself) and a slower one for highly optimized production releases.
Yes, that's one answer. But I actually think you can absolutely have both in the same compiler. But you need to have two backends, as I described. You use the custom backend for development (fast to compile) and you use LLVM for release (fast to run).
Well yes, but at that point aren't you effectively writing two compilers in one? It seems to me that would be at odds with wanting it to be fast to compile itself (you said under 30s) and would make it more difficult for the uninitiated to contribute to.
I don't mean to discourage and I don't disagree with the aims. I just have the (possibly mistaken) impression that compilers inevitably fall on a continuum from simple and fast to complex and slow.
No, you "only" have to write a backend. Which is still a lot of work, but much less work than another compiler. There are multiple ways it can be designed, but one idea that I like the most right now is to create an API for LLVM, and then implement the same API ourselves with a fast backend. That way we reuse everything in current LFortran, including lowering to LLVM, we just have to refactor it to use our own API instead.
It was a lot of corner cases that we had to get right, it's the most advanced code that LFortran can compile. I think none of the features individually is difficult to support, but there were a lot of them.
Does anyone know how many transistors were on each chip?
The complete system of 28 chips had 74,442 transistors. From that it follows that some chip had at least 74,442 / 28 = 2,659 transistors. But I am guessing some chips had less, and some chips had more. I am curious how many transistors the chips had on this computer, specifically what was the maximum amount per IC.
Yes, I also like The Theoretical Minimum. Ha, I didn't realize there is more than one book! I think I only have the classical mechanics book. Need to buy the other ones.
I tried to organize many physics subjects in a similar manner, with many worked out examples (minimal, but non-trivial/complete):
The demo at https://dev.lfortran.org uses our direct WASM backend that does not use LLVM. It is currently more limited, and indeed, we currently do not support the cubic power x**3 there, only square power x**2. Our most advanced backend is LLVM, and that of course supports x**3 and a very wide subset of Fortran (such as 60% of all SciPy packages fully compile and all SciPy tests pass). However, LLVM is huge and relatively slow, so we do not use LLVM in the online demo, which runs the compiler itself in the browser.
For offline LLVM based WASM compilation I think LFortran is ready be tried. We'll be happy to help!
I’ll definitely be trying out more of LFortran in the future.
For this post I really wanted to go deeper into the approach we’ve taken with flang, but I can see that LFortran is also a very strong choice here for running Fortran on Wasm.
Thanks. Please report all bugs that you find. I talked to my collaborators, we'll try to get some simple demo of Fortran->LLVM->WASM working soon, we need to figure out the runtime library issue (like you did), hook it into the driver, etc. I was in fact thinking about exactly this just last week, to easily distribute my simple computational codes online via static pages.
I think exactly the approach that you took with Flang should work with LFortran also.
Nothing, we can compile x*3. We can't compile x**3, because we do not have a runtime library setup for WASM yet (Flang above had the same issue) and WASM can do x**2, but arbitrary power, such as x**3, requires a runtime power function that we haven't implemented yet. If you want to help, you can fix it probably quite easily right here: https://github.com/lfortran/lfortran/blob/69d488b1d1fd26b163....
Wow, this looks great. Seems like there is a mini-renaissance of Fortran that I've been seeing lately. I see from the main page:
"LLVM makes it possible to run LFortran on diverse hardware and take advantage of native Fortran language constructs (such as do concurrent) on multi-core CPUs and GPUs."
...is LFortran close to using coarrays, etc, and farming it out as appropriate to the GPU cores?
We are progressing. We'll tackle parallel loops very soon, and get some GPU offloading working. Our main focus is still on just compiling Fortran codes via LLVM. Once we can compile most codes, we'll focus on the various other backends, including GPU, running in the browser and Jupyter.
LFortran error messages style got inspired by Rust, and the Fortran Package Manager got inspired by Cargo. And in return Rust can get inspired by LFortran to do the interactive prompt. :)
In all seriousness though, Rust got many things right and showed how a modern language, compiler and a package manager should behave. I think it genuinely moved the state-of-the-art. And we are trying hard to improve on the state-of-the-art as well. I think a modern compiler should compile fast in Debug mode, and generate high performance code in Release mode. And it should compile to a binary as well as work interactively. Etc.
