Table of Contents

The Chapel developer community is pleased to announce the release of version 2.1 of Chapel! This release builds on March’s milestone 2.0 release by significantly expanding Chapel’s installation options and improving support for AWS. It also adds powerful new features like remote variable declarations and language support for GPU reductions. In this post, I’ll provide an overview of these advances and summarize a few other highlights.

Installation/Portability Improvements

A big theme of the Chapel project since completing the 2.0 release has been thinking expansively about [note:For those interested, I introduced this theme and ran through some of our recent efforts here in my "State of the Chapel Project" talk at ChapelCon '24, whose slides and video are available online. ]. One effort we’ve kicked off as a result of this seeks to improve and diversify the options for installing Chapel on a given system.

Specifically, where we have traditionally supported Chapel system installations through source builds, Homebrew, Docker, and the HPE/Cray module systems, in Chapel 2.1, we’ve added new installation options and improved some of the existing ones. Here are some of the highlights:

Spack

The first—and to me, most exciting—new installation option is a full-fledged Chapel Spack package. If you’re not familiar with Spack, think of it as the package manager of choice for HPC systems—though it works great on laptops and workstations as well! Spack’s development was led by HPC experts at LLNL, and was designed with a supercomputer’s needs and configurations in mind, where traditional package managers have typically fallen short.

If you’ve built Chapel from source, you’re likely aware of the wide variety of knobs and configuration options that can be used to customize the installation. The Chapel Spack package exposes these options as Spack variants, while also leveraging Chapel’s existing logic to pick reasonable defaults for a given system or network.

To get started with Chapel in Spack, refer to its new Installing via Spack webpage. And thanks very much to Dan Bonachea (LBNL) and Peter Scheibel (LLNL) for their considerable help in reviewing, testing, and improving this new Chapel package during its development.

Linux Packages

If you manage a Linux system and prefer using its native package manager, for Chapel 2.1, we’ve started releasing Chapel as RPMs and Debian (.deb) packages. This simplifies installation on popular Linux systems such as Ubuntu, Debian, Fedora, and RHEL by only requiring a download and a single dnf install or apt install command to get started.

Currently, these packages are being made available in single-locale formats for those wanting to run on their Linux laptop or workstation. For many flavors of Linux, we’re also releasing multi-locale versions that support running on commodity clusters.

Our multi-locale packages are currently built using Chapel’s GASNet-EX/UDP configuration for portability. This permits these packages to run on any network that supports TCP/IP, such as Ethernet. In the future, we plan to add additional packages to support high-performance networks like InfiniBand. We also anticipate supporting more package managers over time. If there are specific configurations that you would like to see prioritized, please let us know!

To learn more about this installation option, see our new Installing Chapel using Linux Package Managers page.

Homebrew

Homebrew is a package manager that we’ve supported for some time now, and an important one due to its popularity in the Mac OS X community. In Chapel 2.1, we’ve improved our Homebrew formula to use the preferred single-locale configuration, leveraging Qthreads from Sandia National Labs, hwloc from the OpenMPI community, and jemalloc. These changes should result in performance boosts and better utilization of desktop hardware, particularly for workstations that have a mix of performance and efficiency cores.

To leverage these improvements, see Installing Chapel using Homebrew.

AWS EFA

Another aspect of deploying Chapel that we’ve been working on for version 2.1 is getting it running well on cloud providers, such as AWS (Amazon Web Services). Specifically, we’ve made a lot of great progress improving Chapel execution using AWS’s Elastic Fabric Adapter (EFA) network interface, in terms of both stability and correctness. In future releases, we plan to support pre-packaged installations of Chapel for AWS/EFA, but in the meantime, we’ve updated our Using Chapel on Amazon Web Services documentation to reflect current best practices.

Remote Variable Declarations

Chapel 2.1 provides a prototype implementation of a feature that’s been planned since Chapel’s inception, yet never implemented. The idea is to prefix a variable declaration with a traditional on-clause to have the variable be allocated on a specific locale:

1
2
3

  on Locales.last var x = 42;
  writeln("I'm running on locale ", here.id,
          ", but x is stored on ", x.locale.id);

The benefit of this feature is that it permits a variable to be stored anywhere on the system, yet without having its lifetime be bound to the lexical scope that a traditional on-clause would introduce:

 5
 6
 7
 8
 9
10

  on Locales.last {
    var x = 42;
    writeln("I'm running on locale ", here.id,
            ", and x is too (", x.locale.id,
            "), but only for this on-clause's scope");
  }

Until now, Chapel’s classes were the only other way to decouple a variable’s location from its scope, but that approach requires more code and effort to declare the class and manage its lifetime. For simple cases like the one above, it ends up feeling like overkill.

This new remote variable feature is particularly important for programming GPUs with Chapel since the top-level control logic can run on the CPU while declaring variables that are allocated in GPU memory and used across multiple GPU kernel launches.

To learn more about this feature, refer to the Remote Variable Declarations tech note in Chapel’s documentation.

GPU Reductions

Speaking of GPUs, Chapel 2.1 continues to advance Chapel’s support for GPU programming through a number of feature improvements and bug fixes.

As a specific example, in Chapel 2.0, computing a reduction of an array to a scalar using a GPU required calling to library routines like gpuSumReduce(myGpuArray). For Chapel 2.1, we have extended Chapel’s reduce expressions and intents so that traditional Chapel patterns like:

var sum = + reduce myGpuArray;

or:

var sum: real;
forall i in 1..n with (+ reduce sum) do ...

can now be used to execute the reduction on a GPU.

For more information about Chapel on GPUs, please refer to our ongoing GPU Programming in Chapel blog series or the GPU Programming tech note.

Other Chapel 2.1 Highlights

In addition to the items called out above, Chapel 2.1 contains many other improvements in terms of features, performance, documentation, and bug fixes, many of which have been motivated by user feedback or requests. Here are a few highlights:

For a more complete list of changes in this release, please refer to its CHANGES.md file. And thanks to everyone who contributed to Chapel 2.1!

For More Information

If you have questions about the release or its new features, please reach out on Chapel’s Discourse community or one of our other community forums. As always, we’re interested in feedback on how we can make the Chapel language, libraries, implementation, and tools more useful to you.