Parallelizing `loo`

I’m excited to be accepted into the GSOC 2026 cohort, continuing to work on loo, but this time focusing on parallelizing loo⁠. I did GSOC last year as well, also working on loo. This year there were 1,141 accepted contributors from a pool of 15,245 (23,371 proposals), working out to an acceptance rate of around 7.5% (4.9%). Again, this was the only proposal I submitted.

In case you aren’t familiar, loo⁠ [1] is a widely used R package for cross-validating Bayesian models. Broadly, we are going to be working on updating and extending the existing parallelization approach in loo. Currently, some loo functions use parallelization by way of forking processes, which doesn’t work on Windows but has some benefits over other parallelization schemes with respect to memory. The mirai package [2] is a new approach to cross-platform parallelization which relies on daemons, allowing package developers to write parallel code without any knowledge of where the code will be executed—allowing users to scale up to any number of local or remote cores. mirai represents one approach to updating loo’s approach to parallelization.

After this project, users of loo will be able to run some expensive calls in parallel, regardless of the OS they use, and ideally in any environment they would like—be it a SLURM cluster, SSH access to a large server, across a homelab, or just across many cores on their own machine.

Technical Details

The relevant issue is #308⁠

Currently loo relies on the parallel package from base R [3] to parallelize certain computations, such as moment matching, Pareto smoothed importance sampling [4], and more. parallel is a common option for parallelization due to being part of base R and relatively easy implementation. Additionally, parallel exposes an API which allows for forking, allowing child R processes which start as copy-on-write clones of the parent process, thereby eliding some memory/compute costs required by spinning up fresh R processes in other parallelization strategies—which may require expensive recompilations of C++ code. Note that forking is only supported on Unix derived systems, for our purposes, Linux and MacOS—Windows cannot use forking in the same way, and relies on fresh R processes. While forking is quite effective, there are a number of downsides to using parallel and loo’s current parallelization approach.

The first gripe is, of course, that forking doesn’t work on Windows. loo’s approach to dealing with this issue is maintaining two paths whenever parallelization is used: a forking method for non Windows, and a non-forking (sockets) approach for Windows. Reducing this duplication is a software engineering benefit, but wouldn’t directly impact users.

More importantly, using a different parallelization strategy may allow for performance improvements—especially on the Windows path, ideally by reducing the overhead needed to parallelize code there. Further, packages such as mirai would allow for users to parallelize execution over heterogenous compute resources (e.g., over local cores, a distributed systems, GPUs, or any mixture). This freedom decouples execution profiles from loo’s software, allowing users with varying compute needs to exploit their available resources without any extra work. A major part of the project here would be writing strong documentation which teaches users how to make use of some common resources such as SLURM or SSH access to users, building off of the documentation in packages like mirai, but with a focus on applications to loo.

In short, we will update loo’s parallel execution backend to be more stable across OSes as well as more performant and scalable. This is achievable due to modern libraries such as mirai or futurize and the futureverse [5] which have been designed to be low latency, scalable, and generally very performant. loo’s adoption of such dependencies will allow for users to exert more control over the execution of parallel code and allow them to scale neatly, as needed. We will also write documentation detailing, broadly, when such scaling is necessary and how to access certain common compute resources through the simple, unified interface provided by the parallelization backend.