We are thrilled to announce that LFortran supports all intrinsic functions listed in F2018 Interpretation Document (Table 16.1 Pg: 332) (also shown by this nice list online at GFortran’s documentation). This comprehensive list of almost 200 intrinsics encompasses a broad array of functions and subroutines essential to Fortran’s functionality, including elemental, inquiry, transformational, array operations, and more. For each function we support both compile-time and runtime evaluation.

The functions are implemented in an ASR (Abstract Semantic Representation) pass, which means they get “instantiated” and specialized for the argument types and then the compiler can optimize it, so using any intrinsic function is at least as fast as implementing the same operation yourself, there is no runtime overhead.

We are thrilled to announce that LFortran can now successfully compile and run lanl/SNAP, marking a significant milestone in our journey to beta. SNAP is the seventh production-grade, third-party code that LFortran can compile, bringing us closer to our goal of compiling 10 such codes—a critical step toward a beta-quality compiler.

About SNAP

SNAP (SN Discrete Ordinates Application Proxy) is a proxy application designed to emulate the performance of modern discrete ordinates neutral particle transport codes. It replicates the computational workload, memory requirements, and communication patterns of the Los Alamos National Laboratory code PARTISN, without including actual physics. By using domain decomposition and parallelization across spatial, angular, and energy domains, SNAP is ideal for performance testing on cutting-edge high-performance computing systems.

In early June, we announced a significant achievement with LFortran: the Fastest Open-Source Compiler in Compile-Time Evaluation of an Array Benchmark. Continuing our commitment to performance enhancement, we are pleased to announce that LFortran now includes support for OpenMP pragmas and parallelizing do concurrent. Particularly for parallel do OpenMP construct, our implementation is fully operational and achieves performance comparable to GFortran.

Note that LFortran is still a alpha software, meaning that users must continue expecting that LFortran will fail compiling or running their codes. Please report all bugs that you find.

After successful compilation of stdlib and Fortran On Web Using LFortran, we focused on improving the support for compile time computation and we are excited to announce that LFortran can now compile the example from the Computing at compile time Fortran Discourse topic.

This example can be used to benchmark the speed of compilation and compile-time array evaluation by increasing the size of the arrays. On this particular example LFortran outperforms other open-source Fortran compilers by an order of magnitude for large array sizes. For small array sizes each compiler has a different constant overhead, which becomes negligible for large arrays and this benchmark measures how quickly the compiler can internally apply the symbolic function on a large array numerically.

Fortran On Web Using LFortran

Recently, there was a blog post titled Fortran on WebAssembly released by Dr George W Stagg. This article inspired us to compile the same example using our LFortran compiler. We are happy to share that we have the fortran mnist classifier example used in the blog post, compiled to WebAssembly using LFortran (with no hacks to the compiler) and working perfectly in the browser.

MNIST

We cloned the original authors code and just swapped-in two of our generated files mnist.js and mnist.wasm with the original files. We also fixed few minor bugs in the code that we came across (details in the commit history).

LFortran compiles 85% Fortran stdlib

We are happy to announce that LFortran can compile all numerical modules in stdlib. The stdlib library has 32 modules, here are the details of the current status:

• all 32 modules compile to ASR
• 27 modules (85%) compile to LLVM; there are 4 hash modules (hash_32bit, hash_64bit, hashmaps, hashmap_wrappers, stringlist_type) and one stringlist_type module that does not compile to LLVM yet
• 24 modules pass all their tests; 3 modules (sorting, bitsets, stats) do not pass all tests yet, but simple examples that use the modules work

This is sixth third-party production-grade code that LFortran can compile after SciPy. The progress bar towards beta has thus reached 6/10.

LFortran Compiles 60% of SciPy

With successful compilation of dftatom in October 2023, embarking to the new year with a remarkable stride, we are delighted to announce that LFortran can now successfully compile 9 out of the 15 Fortran packages within the SciPy library without requiring any modifications.

This is the fifth third-party production-grade code that LFortran can compile. The progress bar towards beta has thus reached 5/10.

LFortran can now compile and pass tests written for scipy.special.specfun, scipy.special.cdflib, scipy.special.amos, scipy.special.mach, scipy.optimize.minpack, scipy.optimize.minpack2, scipy.interpolate.fitpack, scipy.integrate.quadpack, and scipy.integrate.mach.

After compiling fastGPT in September 2023, today we are happy to announce that LFortran can compile and run dftatom without any modifications, and dftatom’s continuous integration (CI) now tests every commit with LFortran, along side GFortran.

This is the fourth full third-party production-grade code that LFortran can compile. The progress bar towards beta has thus reached 4/10.

It can compile the main application in Debug mode twice faster than GFortran. In Release mode the runtime performance is within a factor of 2x slower than GFortran’s Release mode (all optimizations on).

In our last blog post from May 2023, we announced that LFortran can compile legacy and modern Minpack. Today, we are happy to announce that LFortran can compile and run fastGPT.

This is the third code that LFortran can compile. The progress bar toward beta has progressed to 3/10.

LFortran is still alpha, meaning that users expect frequent bugs and breaking changes. Alpha users are enthusiastic partners in the effort to reach beta and they dilligently report issues. In beta, users will expect LFortran to compile their codes, but users will still be partners in reporting remaining issues.

Two days ago on April 30, 2023 was the 4th anniversary of LFortran’s initial release. Our initial prototype in 2019 was in Python. Since then we have rewritten to C++ for speed and robustness. In 2021 we announced an MVP.

In this update, we are happy to announce that LFortran can compile and run both legacy and modern Minpack. We’ll start off by taking a look at the current compilation status and benchmarks of minpack. From there, we’ll provide an overview of where LFortran is currently at and share our next steps going forward.

LFortran has evolved rapidly since its inception and is now close to beta status. Several key project progress goals are on track with the help of external support; and the recent GSoD support will galvanize the documentation and ease the onboarding of new contributors to the language and LFortran’s unique tooling.

At the heart of the L-family of compilers (LFortran, LPython) lies the idea that there are invariants across languages which can be documented and worked with. To this end, LFortran has decided to kick-start a sustained period of documentation generation for both the Fortran language (in terms of compiler implementation records) and the ASR itself. The relatively higher technical debt required for the task at the moment made it inefficient to look too far away from the existing community, and Rohit Goswami and Tapasweni Pathak will be the two technical writers for this 2022 season of documentation. You can look at our GSoD proposal for more details.

After a little over 2 years from our initial announcement, we are releasing LFortran MVP today.

We have set our goal to release MVP in September 2021. We were initially hoping to compile at least some production codes for MVP. While we did not quite get there yet, after wrapping up and documenting where we are and writing a demo Fortran project that works with the MVP, it turns out LFortran is already quite usable and it can compile quite a lot of computational Fortran code if you are willing to work around some of the current limitations. In this blog post we will describe in detail the current status of LFortran.

We received a lot of positive feedback on our LFortran announcement. Most generally like the idea and tool, and expressed interest to hear a bit more on why we think Fortran is a superior language in its domain and why it makes sense to use Fortran for new projects.

Why Fortran?

Fortran was designed from the ground up to naturally and simply translate mathematics to code that compiles and runs at maximum speed. And being specifically targeted for such fundamentally computational tasks, it contains a broad range of key functionality within the language itself, standard across all platforms, with no need for external libraries that may or may not be well optimized or maintained, at present or down the road.

We recently open sourced LFortran, an interactive Fortran compiler built on top of LLVM that we have been developing for the last 1.5 years. It is a work in progress and at the link you can find what works already, what is planned and a roadmap.

Here is our motivation.

Why are almost no new scientific or engineering software projects started in Fortran?

Usually (in our neck of the woods) C++ is chosen instead. The following are the most cited reasons for such a choice: