certik

Great work, I am glad LFortran worked well for this work. We are very close to beta quality now, many codes just work, pretty much all Fortran features are implemented now, but some codes still don't compile due to various small bugs, so we've been fixing them all in the last couple months.

We can internally do both row-major and column-major arrays. For Fortran we enable the column-major flag by default, but the door is open to have both at the same time.

Just wanted to say big thanks to the maintainers, I've been using tectonic the last couple years as my only LaTeX distribution, works everywhere (including macOS), it's available in conda-forge, so I can just have it as a dependency in my projects. Everything "just works", that's the best way to describe it.

Thank you for fully fixing LaTeX for me.

I do come from the scientific community, so didn't know until today that not every community uses the term "codes".

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.

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.

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

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

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.

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.

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.

Beautiful! I would like to see more cursive handwriting fonts. Here is my contribution from 2 years ago:

https://certik.github.io/slabikar-otf/

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.

The LLVM backend just does the usual floating point calculation for those.

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

https://www.theoretical-physics.com/dev/index.html

Thank you!

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

The author of LFortran here.

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!

GFortran, Flang and LFortran are all open-source compilers that support modern Fortran.

Awesome! Report all bugs. :)

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.

Yes indeed, we'll do it next (unless somebody beats me to it). First I am focusing on compiling fastGPT with LFortran, we can do it, but have a few workarounds that I want to fix. Then we'll do llama2.

It can be both. If you know the dimension at compile time, it is compile time, if you don't it will be runtime.

Yes, there are many nice people there and we are doing what we can to moderate the Discourse so that we can all have a nice place to discuss.

Peter, I am sorry that some users drove you away, possibly myself included. I am personally doing what I can to keep the Fortran open source (and commercial) community together, I have done this before (e.g., with SymPy), and the Fortran community can be very tough in some of the responses. I know most of the people in person, and they are all very nice people.

We regularly address unconstructive behavior. If you or anyone has some feedback how we can run things better, please let me know (you can email me at ondrej@certik.us).

LFortran can translate your Fortran code to Julia via our Julia backend. Once Julia can compile to a binary, it will be exciting to do some comparisons, like speed of compilation and performance of the generated binary. As well as the quality of the Julia code that we generate, we'll be happy to improve it to create canonical Julia code, if at all possible.

Yes, both LPython and LFortran are our two thin frontends to ASR (Abstract Semantic Representation). Not just the website is reused, but the internals are reused, so LPython runs your code at exactly the same speed as LFortran would, since ASR and all optimizations and backends are shared.

It's hard to have a fair comparison, and both compilers are also moving targets. I tried to do some comparison in a sibling comment: https://news.ycombinator.com/item?id=37300279

The best is to mention both (as well as GFortran), and users can decide. For LPython (https://lpython.org/) we list all of the about 30 Python compilers at the webpage, but beyond that it's very hard to have a meaningful comparison.