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