Chapel 2.9: Dynamic Libraries, LLVM 22, and CUDA 13 Support

Chapel 2.9 shipped on June 18 with LLVM 22 and CUDA 13 support, a prototype of dynamic library loading for distributed parallel code, a browsable Mason package registry, and union types. The release targets HPC and GPU workloads, enabling modular architectures and compatibility with modern NVIDIA AI stacks.

Chapel 2.9 shipped on June 18 with backend upgrades that mean more than their version numbers suggest. LLVM 22 and CUDA 13 support land in the same release as the first working prototype of dynamic library loading for distributed parallel code — plus a browsable Mason package registry and union types that have finally left a years-long “half-baked state.” For developers working at the intersection of HPC and modern GPU workloads, this is a release worth tracking. Dynamic Library Loading: The Feature That Was Always Blocked The headline capability is also the most architectural one. Chapel has had a DynamicLoading module since version 2.5, but with a significant catch: it could only load C or C-like libraries. Chapel libraries that used the language’s core features — parallelism and distributed memory across multiple locales — were explicitly excluded. That limitation is addressed in 2.9. The mechanism is a new compiler flag, --no-builtin-runtime , which allows distinct Chapel binaries to share a single dynamically loaded copy of the Chapel runtime. Previously, every binary bundled its own runtime copy, which created resource contention and prevented coordination between programs running side by side. The shared runtime is the prerequisite that makes composable, plugin-style HPC architectures possible. The Chapel team is candid about the state of this feature: it is labeled prototypical, and you may encounter bugs that prevent the loaded program from running. OFI communication support is still pending. This is a foothold, not a finished API. That said, the direction is clear, and for teams exploring modular HPC pipeline design, this is the moment to start experimenting. LLVM 22 and CUDA 13: The GPU Stack Gets Current Chapel 2.9 adopts LLVM 22 as its default compiler backend, with LLDB 22 for debugging. The practical consequence is CUDA 13 support — LLVM versions older than 22 cannot compile for CUDA 13, making the backend upgrade a prerequisite rather than a standalone choice. For GPU programming, the default architecture is now sm 75 for CUDA 13+ targets, configurable via the CHPL GPU ARCH environment variable or the --gpu-arch compiler flag. This matters because HPC centers are no longer running just simulations — LLM training and inference workloads are landing on the same exascale hardware. CUDA 13 https://developer.nvidia.com/blog/nvidia-cuda-13-1-powers-next-gen-gpu-programming-with-nvidia-cuda-tile-and-performance-gains/ compatibility puts Chapel on the same GPU generation as the current NVIDIA AI stack. Chapel’s GPU programming model is worth a brief note for the uninitiated. The language lets you express parallelism with forall loops that the compiler can automatically target to GPU execution, without CUDA boilerplate. For researchers who know HPC but haven’t written CUDA kernels, this is the right abstraction. You can drop into custom CUDA code for performance-critical paths, but the common case doesn’t require it. Mason Gets a Package Browser — and Parquet Mason, Chapel’s package manager, now has a web-based browser at chapel-lang.org/packages/ https://chapel-lang.org/packages/ . That may sound minor, but package discoverability is how ecosystems grow. New modules published since Chapel 2.8 include: Parquet Parquet IO , Crypto OpenSSL-based cryptography , CVL vectorization , Base64 , Log , Pathlib , SciChap , TemplateStrings , and TerminalColors . The Parquet module deserves a mention on its own. Parquet is the file format that connects HPC simulation output to data science pipelines. Having a native Chapel Parquet module closes a gap that previously required a round-trip through Python or C. It is not glamorous, but it is the kind of bridge that makes a language usable in production data workflows. Tooling and Language Refinements The Chapel Language Server CLS received several improvements for VSCode users: compiler errors are now highlighted more precisely in the editor, return types and iterator yield types are inferred and displayed, and generic procedure rendering now collects instantiations across multiple project files. These are the quality-of-life changes that separate a language people evaluate from one they use every day. On the language side, union types finally have default comparison operators. Two unions of the same type are now equal if they share the same active field with equal values — a straightforward semantic that should have existed for years but did not. Separately, scans over array-like expressions are now parallelized, which is a meaningful performance improvement for workloads that use prefix operations. Getting Chapel 2.9 Chapel 2.9 is available through the official release announcement https://chapel-lang.org/blog/posts/announcing-chapel-2.9/ , which includes download links and installation instructions. HPE Cray EX users on RHEL now have RPM packages available — a packaging format that simplifies deployment on production HPC clusters. The project is hosted on GitHub https://github.com/chapel-lang/chapel and is a member project of the High Performance Software Foundation https://hpsf.io/projects/chapel/ .