gCAMB: GPU-Accelerated CAMB for CMB Analysis

• gCAMB is a GPU-accelerated version of CAMB designed to compute CMB angular power spectra faster while preserving all original features.
• It offloads the computationally intensive line-of-sight integrals to the GPU, achieving significant speed-ups and reducing energy consumption by over 50% in high-accuracy settings.
• gCAMB integrates seamlessly with existing CAMB workflows, facilitating the generation of extensive training sets for cosmological parameter inference without altering core physics.

gCAMB is a GPU-accelerated port of CAMB for the calculation of theoretical angular power spectra in Cosmic Microwave Background parameter inference. It is presented as a version of the CAMB code ported to GPUs that preserves all the features of the original CPU-only code, while offloading the most computationally intensive modules to the GPU in order to accelerate the generation of power spectra, save computational time, halve power consumption in high-accuracy settings, and facilitate the creation of extensive training sets for robust cosmological analyses (Storchi et al., 29 Sep 2025).

1. Problem setting and scope

Inferring cosmological parameters from Cosmic Microwave Background data requires repeated and computationally expensive calculations of theoretical angular power spectra using Boltzmann solvers like CAMB. The paper identifies this as a significant bottleneck, particularly for non-standard cosmological models and the high-accuracy demands of future surveys. It also contrasts this approach with emulators based on deep neural networks, which can accelerate the process by several orders of magnitude but first require large, pre-computed training datasets that are costly to generate and model-specific (Storchi et al., 29 Sep 2025).

Within that setting, gCAMB is positioned as a direct acceleration of CAMB itself rather than as an emulator. The stated objective is not to alter the physical calculation, but to port the expensive part of the existing workflow to GPU hardware while preserving compatibility with the original code base. This suggests a design aimed at reducing the computational bottleneck without introducing the model-specific training burden associated with neural-network surrogates.

2. Computational design and numerical formulation

The targeted module is only the line-of-sight projection, identified as “SourceToTransfers” in CAMBmain. This routine, for each wavenumber mode $q$ and each multipole $\ell$, accumulates integrals of the oscillatory source functions against spherical Bessel kernels. By contrast, the ODE integrator that computes the source functions $S_T(q,\tau)$ and $S_P(q,\tau)$ remains on the CPU unchanged, and primordial spectra and eigenmode solvers are likewise untouched (Storchi et al., 29 Sep 2025).

The port uses OpenACC directives. The core multipole-time loops are enclosed in a single accelerator data region; inputs such as $\tau$, $S_X$, and Bessel-kernel tables are copied in once, while the transfer functions $\Delta_\ell^X(q)$ are copied back at the end. Coarse-grain parallelism (gang) is over the outer $q$-loop, and fine-grain parallelism (vector) is over $\ell = 1 \ldots \ell_{\max}$ and, nested inside, over the line-of-sight sampling index $n = n_{\min} \ldots n_{\max}$. The mapping is described as natural to CUDA: each gang corresponds to a CUDA block, and each vector lane to a CUDA warp or set of threads. Shared versus global memory management for Bessel-kernel lookup tables is delegated to the compiler (Storchi et al., 29 Sep 2025).

The numerical kernel is explicitly described as preserving Seljak & Zaldarriaga’s line-of-sight integrals:

$\ell$0

$\ell$1

The implementation discretizes $\ell$2 and rewrites each transfer function as

$\ell$3

The paper states that all $\ell$4 and $\ell$5 loops are simply vectorized on the GPU, so no novel algorithmic reformulation was required—only a relocation into GPU address space with minimal data movement. A plausible implication is that gCAMB’s performance gains arise primarily from hardware utilization and loop-level parallelism rather than from changes to the mathematical structure of the Boltzmann calculation.

3. Runtime characteristics and numerical fidelity

The reported benchmarks use 32 cores of an Intel Xeon Platinum 8358 (2.6 GHz) for CPU-only runs and one NVIDIA A100 on the Leonardo Tier-0 EuroHPC system for GPU runs. gCAMB was built with NVIDIA’s nvfortran 24.5 with OpenACC, while CPU-only CAMB was built with GNU Fortran 8.5. The paper defines three accuracy settings through $\ell$6: Low $\ell$7, Medium $\ell$8, and High $\ell$9. All runs compute $S_T(q,\tau)$0 and $S_T(q,\tau)$1 (Storchi et al., 29 Sep 2025).

The end-to-end runtimes reported for “All [s]” are as follows.

Accuracy	Method	Total [s]
Low	CAMB single core (serial)	26.8
Low	CAMB OpenMP (32 thr)	1.56
Low	gCAMB (GPU+CPU, 32 thr)	1.86
Medium	CAMB single core	588.2
Medium	CAMB OpenMP (32 thr)	32.2
Medium	gCAMB (GPU+CPU, 32 thr)	16.8
High	CAMB single core	6246.6
High	CAMB OpenMP (32 thr)	329.9
High	gCAMB (GPU+CPU, 32 thr)	54.0

The paper further reports speed-up factors relative to serial single-core CAMB. For the SourceToTransfers kernel alone, the speed-up reaches up to approximately $S_T(q,\tau)$2 versus OpenMP-32 and approximately $S_T(q,\tau)$3 versus serial in the High-accuracy case. End-to-end, High-accuracy runs go from approximately $S_T(q,\tau)$4 on 32 CPU threads to $S_T(q,\tau)$5 on GPU, corresponding to approximately $S_T(q,\tau)$6 speed-up; versus serial the figure is approximately $S_T(q,\tau)$7 (Storchi et al., 29 Sep 2025).

Numerical accuracy is evaluated by comparing gCAMB and CAMB spectra for TT, TE, EE, and BB up to $S_T(q,\tau)$8. The reported fractional differences $S_T(q,\tau)$9 are typically $S_P(q,\tau)$0, always $S_P(q,\tau)$1. In every multipole bin, $S_P(q,\tau)$2 is stated to be at least $S_P(q,\tau)$3 below full-sky cosmic variance $S_P(q,\tau)$4, and the paper therefore characterizes the differences as fully negligible for inference (Storchi et al., 29 Sep 2025). This addresses a central concern for accelerated Boltzmann solvers: the implementation is described as materially faster without introducing numerically relevant distortions at the power-spectrum level.

4. Power consumption and efficiency

The energy measurements are reported on a test machine consisting of an NVIDIA RTX 6000 Ada Generation and a dual AMD EPYC 9224 system using 32 threads. For a High-accuracy run, CPU-only CAMB with 32 threads drew $S_P(q,\tau)$5, whereas gCAMB using CPU+GPU drew $S_P(q,\tau)$6 (Storchi et al., 29 Sep 2025).

These measurements imply that gCAMB uses approximately $S_P(q,\tau)$7 less energy in high-accuracy settings. The measurement tools are specified as perf for CPU and nvidia-smi for GPU. The paper also notes a trade-off at low accuracy: GPU “warm-up” overhead of approximately $S_P(q,\tau)$8 can offset the benefits. For medium and high accuracy, however, the lower power-time product is presented as clearly favorable (Storchi et al., 29 Sep 2025).

This operational profile suggests that gCAMB is most advantageous in regimes where line-of-sight projection dominates wall-clock time. It is therefore particularly aligned with demanding survey settings and bulk generation workloads rather than with very short, low-accuracy runs.

5. Pipeline compatibility and dataset generation

gCAMB is described as a drop-in replacement that preserves all of CAMB’s input/output and FORTRAN modules except for the offloaded line-of-sight integrator. No changes are needed in CosmoMC or MontePython other than linking to the gCAMB executable. The installation procedure reported in the paper is based on cloning the gpuport branches of CAMB and forutils, loading nvhpc/24.5 and cuda/12.x, compiling with make compiler=nvfortran OPENACC=1, and running ./camb gpu_params.ini (Storchi et al., 29 Sep 2025).

The stated dependencies are NVIDIA HPC SDK / nvfortran 24.5+, CUDA 11.0+, and OpenACC. The hardware requirement is any CUDA-capable GPU with compute capability $S_P(q,\tau)$9, with testing reported on A100 and Ada RTX6000 (Storchi et al., 29 Sep 2025).

A central use case is the generation of neural-network training sets. The paper gives explicit throughput estimates:

Setting	GPU time	CPU time
Medium accuracy per model	16.8 s/model	32.2 s/model
Medium accuracy for $\tau$0 spectra	19.4 days	37 days
High accuracy per model	54 s/model	330 s/model
High accuracy for $\tau$1 spectra	62.5 days	382 days

These figures situate gCAMB as infrastructure for both direct inference and emulator preparation. The paper explicitly frames the software as facilitating the creation of extensive training sets needed for robust cosmological analyses (Storchi et al., 29 Sep 2025). A plausible implication is that the software reduces not only single-run latency but also the practical cost of model-specific surrogate construction.

6. Constraints and projected extensions

The current implementation has several explicit limitations. Only the flat-Universe integrator, DoFlatIntegration, is offloaded; curved universes, which require hyperspherical Bessel kernels, remain on CPU. The paper also identifies an NVFORTRAN/OpenACC compiler issue that prevents full OpenMP + GPU mixing in some polymorphic regions, with the expectation that future compiler versions will remove this limitation. In addition, the implementation is single-GPU only, with no multi-GPU scaling yet, and the source-function ODE step remains a serial-in-time Runge–Kutta integrator per mode, which can dominate in extended models (Storchi et al., 29 Sep 2025).

The planned extensions are correspondingly specific: porting DoNonFlatIntegration to GPU to accelerate scans over $\tau$2; adding support for massive neutrino hierarchies and modified gravity line-of-sight sources; exploring multi-GPU and NVSHMEM/OpenACC multi-node offloading; benchmarking on next-generation GPUs such as H100 and RTX 5xxx; and integrating gCAMB directly as a backend for MCMC samplers so as to run hybrid CPU/GPU inference without emulator overhead (Storchi et al., 29 Sep 2025).

These limitations clarify the present boundary of the acceleration strategy. gCAMB does not claim to GPU-port the entire Boltzmann pipeline, nor does it eliminate the serial source-function step. Its present contribution is instead to isolate and accelerate the dominant line-of-sight projection while preserving compatibility with existing CAMB-based workflows.