There’s quite a bit to relate to with regards to the main point of the above article, namely that we should have better languages for HPC. However, I think its author “drops the ball” in the second part of the article, i.e. the one that deals with Chapel being a potential alternative to the trio Fortran/C/C++. He writes:
In our project’s experience, we’ve seen the impact that Chapel can have on users’ ability to get things done productively and efficiently […]
I put a part of these claims to the test by comparing the compilation time of the following 50-liner in Chapel
/*
* Jacobi Method Example in Chapel.
*
* This program computes the solution of a Laplace equation using
* the Jacobi method.
*
*/
// Configuration variables for program:
config var n = 300; // size of n x n grid
config var epsilon = 1.e-6; // convergence tolerance
proc main() {
const Domain = {0..n+1, 0..n+1}; // domain including boundary points
var x, xnew: [Domain] real = 0.0; // declare arrays:
// x stores approximate solution
// xnew stores the next solution
var iteration = 0; // iteration counter
var delta: real; // measure of convergence
for j in 1..n do
x[n+1,j] = 1.0; // Set south boundary values to 1.0
do {
// compute next approximation using Jacobi method and store in xnew
for i in 1..n do
for j in 1..n do
xnew[i,j] = (x[i-1,j] + x[i+1,j] + x[i,j+1] + x[i,j-1]) / 4.0;
// compute difference between next and current approximations
delta = 0.0;
for i in 1..n do
for j in 1..n do
delta = max( abs(xnew[i,j] - x[i,j]), delta);
// update X with next approximation
for i in 1..n do
for j in 1..n do
x[i,j] = xnew[i,j];
// advance iteration counter
iteration += 1;
} while (delta > epsilon);
writeln("Jacobi computation complete.");
writeln("Delta is ", delta, " (< epsilon = ", epsilon, ")");
writeln("# of iterations: ", iteration);
}
with that of the following equivalent 50-liner in Fortran (using different compilers):
!
! Jacobi Method Example in Fortran.
!
! This program computes the solution of a Laplace equation using
! the Jacobi method.
!
program jacobi
implicit none
integer(4), parameter :: n = 300 ! size of n x n grid
integer(4) :: i, j
integer(4) :: iteration = 0 ! iteration counter
real(8) :: delta = 1.d0 ! measure of convergence
real(8) :: epsilon = 1.d-6 ! convergence tolerance
! declare arrays
real(8) :: x(0:n+1,0:n+1) ! x stores approximate solution
real(8) :: xnew(0:n+1,0:n+1) ! xnew stores the next solution
! initialize arrays
x = 0.d0
xnew = 0.d0
! set south boundary values to 1.0
x(n+1,1:n) = 1.d0
do while (delta > epsilon)
! compute next approximation using Jacobi method and store it in xnew
do j = 1, n
do i = 1, n
xnew(i,j) = ( x(i-1,j) + x(i+1,j) + &
& x(i,j+1) + x(i,j-1) ) / 4.d0
end do
end do
! compute difference between next and current approximations
delta = maxval( abs(xnew(1:n,1:n) - x(1:n,1:n)) )
! update x with next approximation
x(1:n,1:n) = xnew(1:n,1:n)
! advance iteration counter
iteration = iteration + 1
end do
write(*,*) 'Jacobi computation complete.'
write(*,*) 'Delta is ', delta, ' (< epsilon = ', epsilon, ')'
write(*,*) '# of iterations: ', iteration
end program jacobi
Here are some recent results:
| Language/Compiler | compiler command | compilation time (user + sys) [sec] | compilation time relative to fastest compiler |
|---|---|---|---|
| LFortran (lfortran version 0.62.0) | lfortran --fast jacobi.f90 -o jacobi | 0.235 | 1.0 |
| Intel Fortran (ifx version 2025.1.0) | ifx -Ofast -ffast-math -march=native jacobi.f90 -o jacobi | 0.279 | 1.19 |
| LLVM’s Fortran (flang version 20.0.0) | flang-20 -Ofast -ffast-math -march=native jacobi.f90 -o jacobi | 0.408 | 1.73 |
| Chapel (chpl version 2.8.0) | chpl --fast --ccflags ‘-Ofast’ jacobi.chpl -o jacobi | 22.794 | 97.0 |
In summary, the Chapel compiler needs two orders of magnitude more time to compile this tiny algorithm than any of the Fortran compilers that I know of (which are either listed above or not) – the main result of such comparisons not having changed over the last decade (i.e. the Chapel compiler’s performance in compiling code, relative to Fortran, having shown no significant improvements; For reference: I’ve used Chapel’s C-backend here for simplicity).
Hence, I’ll happily pass. Others apparently feel the same way, as e.g. pklausler in the following comment (that can be found in the linked Hacker News discussion):
Honestly, if a language can’t succeed in HPC alongside (or against) Fortran with its glacial rate of buggy evolution and poor track record of portability, and C++ with its never-ending attempts at parallelism, then it’s not what HPC needs.
(What HPC does need, IMNSHO, is to disband or disregard WG5/J3, get people who know what they’re doing to fix the features they’ve botched or neglected for thirty years, and then have new procurements include RFCs that demand the fixed portable Fortran from system integrators rather than the ISO “standard”.)
Yeah I saw this post on hackernews and the highlighted comment almost motivated me to create an account to respond in agreement with that guy.