Exploring Numba and CuPy for GPU-Accelerated Monte Carlo Radiation Transport

Abstract

This paper examines the performance of two popular GPU programming platforms, Numba and CuPy, for Monte Carlo radiation transport calculations. We conducted tests involving random number generation and one-dimensional Monte Carlo radiation transport in plane-parallel geometry on three GPU cards: NVIDIA Tesla A100, Tesla V100, and GeForce RTX3080. We compared Numba and CuPy to each other and our CUDA C implementation. The results show that CUDA C, as expected, has the fastest performance and highest energy efficiency, while Numba offers comparable performance when data movement is minimal. While CuPy offers ease of implementation, it performs slower for compute-heavy tasks.

1. Introduction

GPU accelerators have emerged as a powerful tool in many areas of science and engineering. They are used for accelerating not only traditional high-performance computing (HPC) applications (e.g., [1,2]) but also for the training and application of AI models (e.g., [3,4]). Many supercomputers in the top 500 list (https://www.top500.org (accessed on 15 November 2023)) obtain most of their computing power from these accelerators (e.g., see [5] for a recent review). Examples include the Aurora, Frontier, and Leonardo supercomputers that use Intel Max, AMD Instinct MI250X, and Nvidia A100 GPUs, respectively.

There are several programming platforms developed for harnessing the power of GPUs, ranging from low- to high-level paradigms. The low-level solutions offer the capability to optimize code for a given family of accelerators at the expense of portability. Popular examples are Nvidia CUDA [6] and the AMD ROCm HIP [7]. The high-level platforms offer ease of implementation and portability at the expense of limited options for optimization for specific hardware. Examples include OpenMP [8], OpenACC [9], OpenCL [10], SYCL [11], Alpaka [12], Numba [13,14], CuPy [15,16,17], Legate Numpy [18], Kokkos [19], RAJA [20], and OneAPI [21].

Many studies have explored how well GPUs perform in various applications [22,23,24,25]. These investigations compare the performance and highlight the strength and weaknesses of popular programming platforms such as CUDA C [26,27,28], CUDA Fortran [29,30,31], OpenCL [32,33,34], OpenACC [35,36], OpenMP [37,38] and Python-based compilers and libraries like Numba, CuPy, and Python CUDA [39,40,41,42,43,44]. Despite these efforts, a quest for a paradigm that offers simplicity of implementation and portability in combination with high performance remains one of the main goals of scientific computing (e.g., [45,46,47,48]).

Radiation transport is used in many areas of science and engineering, ranging from astronomy to nuclear physics (e.g., [49]). In the most general case, it represents a seven-dimensional problem (three dimensions for space, two dimensions for direction, one for energy, and one for time) [50]. This makes it particularly expensive to solve. One popular method for solving the equation is the Monte Carlo method (MC). This method directly simulates the behavior of radiation using random numbers. A group of radiation particles is modeled as an MC particle. MC radiative transfer (MCRT) methods are relatively easy to implement, especially when complicated physics and geometries are involved. The main drawback of the method is its immense computational cost [49].

It is possible to accelerate MCRT calculations using GPUs [51,52,53,54,55,56]. Since the MCRT utilizes a large number of MC particles that are evolved independently from each other (at least, with a timestep), the many-core architecture can evolve particles in parallel, leading to a significant speed-up compared to serial calculations [57,58,59]. There have been many studies and applications of GPU-accelerated MCRT [60,61,62,63]. The generation of random numbers on GPUs was investigated by, e.g., [64,65,66]. Bossler and Valdez [67] compared Kokkos and CUDA implementations of the main MCRT kernels. Hamilton et al. [68] compared history- and event-based MCRT algorithms. The domain decomposition parallelization techniques were explored by, e.g., [69,70]. Bleile et al. [71] explored the so-called “thin-threads” approach to history-based MCRT that achieves lighter memory usage, leading to faster performance. Humphrey et al. [72] implemented a reverse MC ray tracing approach and scaled it to 16,384 GPUs on the Titan supercomputer. Silvestri and Pecnik [73] ported the reciprocal MC algorithm to model radiative heat transfer in turbulent flows using the CUDA programming language, finding a significant speed-up compared to the CPU implementation. Heymann and Siebenmorgen [74] applied the GPU-based MC dust radiative method to active galactic nuclei. Ramon et al. [75] modeled radiation transport in ocean–atmosphere systems with the GPU-accelerated MC code. Their core code is written in CUDA, while the user interface is written in Python CUDA. Lee et al. [76] developed the GPU-accelerated code gCMCRT using CUDA Fortran to perform 3D modeling of exoplanet atmospheres. Several groups explored noise reduction in MCRT using machine learning techniques [77,78,79,80].

In this work, in the context of MC radiation transport, we assess the performance of two popular platforms that allow GPU computing from the Python programming language: Numba [14] and CuPy [16,17]. Both Numba and CuPy are examples of high-level popular platforms (e.g., [39,81]). Their main advantage is their simplicity. Numba is a just-in-time compiler for Python and enables faster performance by translating Python functions into optimized machine code, which is often competitive with manually optimized C code [14]. CuPy provides a simple NumPy-like interface with GPU acceleration [16,17]. Its compatibility with existing Python libraries and support for a wide range of mathematical operations have made it a popular choice for scientific computing tasks (e.g., [82,83]).

There are a number of works that study these platforms in various contexts. Di Domenico et al. [41] observed Numba achieving performance levels comparable to CUDA-based C++ using NAS parallel benchmark kernels. Oden [39] compared Numba with CUDA C, revealing the slower performance of Numba by 50–85% for compute-intensive benchmarks. Peng Xu et al. [84] compared Numba and CuPy in terms of data transfer speed and analyzed the influence of data type on the performance. They found that Numba outperforms CuPy for heavy data transfers, and single precision exhibits a  20% faster performance than double precision. Marowka [43] assessed the performance of Numba in matrix multiplication application. Dogaru R. and Dogaru I. [85] evaluated Numba in reaction–diffusion cellular non-linear networks. Azizi [86] utilized Numba and CuPy, among other Python-based platforms, to optimize expectation-maximization algorithms, yielding promising results. These related works set the foundations for our focused exploration of Numba and CuPy in the context of MCRT.

Our main aim was to study the potential of Numba and CuPy platforms for MCRT calculations. We performed a series of idealized test problems involving random number generation and the one-dimensional MCRT problem in a purely absorbing medium. We performed a detailed analysis of the execution times for three different cards and single- and double-precision calculations. As a benchmark, we compared the results to computations implemented in CUDA C. To the best of our knowledge, there is no existing evaluation of the potential of Numba and CuPy specifically for MCRT problems. The novelty of our work lies in contributing valuable insights into the performance and suitability of these platforms for MCRT simulations.

This paper is organized as follows. In Section 2, we describe our methodology. In Section 3, we present our results. We discuss our findings in Section 4. Finally, in Section 5, we summarize the results and provide conclusions.

2. Methodology

We evaluated the performance of CuPy and Numba for the MC radiation transport problem. We considered two different idealized test problems. In the first problem, we generated pseudo-random numbers (PRNs). We stored the generated PRNs in the global memory, mimicking a scenario that involved heavy memory usage. In the second test problem, we considered a one-dimensional MC transport problem in a purely absorbing medium in a plane parallel geometry. This represented a compute-intensive test as it performed many arithmetic operations (e.g., logarithm, division, multiplication, etc.). The generated PRNs are immediately consumed within the kernel without storing them in the global memory. We compared our results to our implementation in CUDA C. Note that the 1D MCRT test problem was implemented with 15, 26, and 37 lines of code in CuPy, Numba, and CUDA C, respectively, reflecting the ease of implementation in CuPy and Numba relative to CUDA C [41].

We made the computations as similar as possible across the three platforms to ensure a fair comparison. We used the same seed and the same PRNG type Xorshift. More specifically, we used the XORWOW generator from the cuRAND library for the CuPy and CUDA C tests. Since Numba does not support the cuRAND library, we used its Xoroshiro128p PRNG, which belongs to the same Xorshift family. This ensured that all computing platforms were using similar algorithms, facilitating a fair performance comparison. Additionally, we tested the performance of these two generator algorithms and we found no significant difference between them. Therefore, the choice of PRNGs from the Xorshift family aligned to ensure fairness and comparability in the evaluation of PRN generation performance between CuPy, Numba, and CUDA C. Additionally, we ensured that our experiments utilized consistent values for constants and coefficients across all test problems. This guaranteed that any observed differences in performance could be attributed to the platforms themselves rather than variations in PRN generation. For Numba and CUDA C, we took the further step of applying a consistent configuration of grid size, specifying the number of blocks and threads, to efficiently map computations onto the GPU. However, it is important to note that CuPy used its default configuration, reflecting the inherent differences in how each platform manages its parallel computing resources.

Since Numba and CuPy used a just-in-time compilation process, functions were compiled at runtime when they were invoked. Consequently, the first invocation of a function included the compilation step, which can be considerably slower. To avoid this potential bottleneck, we excluded the timing of the first iteration. Additionally, we excluded the PRNG state setup time of CUDA C and CuPy from the GPU kernel performance time, since Numba’s PRNG state setup took place on the host side. Also, unless specified explicitly, the Numba and CuPy platforms assigned double-precision types by default for all floating-point variables and constants. In this regard, we explicitly specified a type for single-precision calculations [39,81].

To assess the performance, we employed the profiling tools nvprof and Nsight Systems. We utilized versions 12.2.0, 0.58.1, 11.8.0, and 3.10.6 of CuPy, Numba, CUDA C, and Python, respectively. We performed 100 measurements for each method and recorded the average value to obtain reliable results. To measure power consumption, we used the tool nvidia-smi. We ran each of our tests for 20 min and recorded the power consumption and GPU utilization parameters every 5 s. Then, we took the average value from these measurements.

We considered three distinct GPU cards: the A100 (in a DGX-A100 server), V100 (in a DGX-2 server), and RTX3080 card. We selected the A100 GPU because it is a relatively recent-generation Nvidia card for AI and HPC and our group had access to it. The V100 GPU is a predecessor to A100. Lastly, the RTX3080 GPU is an example of a high-end card in consumer space (see

Table 1. Technical specifications of GPU cards used in this work.

GPU Card	CUDA Cores	Base Clock [MHz]	FP32 (Float) [TFLOPS]	FP64 (Double) [TFLOPS]	Bandwidth [GB/s]
A100	6912	765	19.49	9.746	1555
V100	5120	1230	14.13	7.066	897
RTX3080	8704	1440	29.77	0.465	760

for key specifications). These cards represent examples of devices that are currently in active use by the scientific community (At the time of preparing this work, we had no access to the latest-generation Nvidia H100 card. Similarly, we have no access to AMD or Intel cards. However, our comparison between A100, V100, and RTX3080 that we present below suggests that the qualitative differences between the three software platforms that we found should remain valid irrespective of the cards used).

Unless otherwise noted, all results presented in Section 3 were obtained using the A100 GPU card. However, for the purpose of comparison, we included the results for the V100 and RTX3080 GPUs in Section 3.3. All computations were performed in single precision, except in Section 3.1, where we compared single- and double-precision calculations.

3. Results

Figure 1 (left panel) shows a performance comparison of CuPy, Numba, and CUDA C for the PRN generation problem. The x-axis shows the number of generated PRNs. The solid lines represent the total execution time from the beginning until the end of the computation, including computations on the host and GPU side. The dashed lines show the GPU kernel execution time, which only measures the time on the GPU. In terms of the total execution time, all platforms performed at the same level for $N\le {10}^6$. For larger N, Numba demonstrated slower performance than CuPy and CUDA C, e.g., by 1.87x and 3.22x at $N=2\times {10}^9$, respectively. CuPy performed similarly compared to CUDA C up to $N={10}^8$. However, for a larger N, CUDA C outperformed CuPy by 1.72x at $N=2\times {10}^9$. When comparing the performance of GPU kernels, CUDA C was faster than Numba and CuPy by 1.21x and 1.67x even at $N={10}^4$. The performance gap widened with increasing N and reached about 22x and 7.8x compared to Numba and CuPy for $N=2\times {10}^9$. These findings are in line with those of previous studies (e.g., [39,41]).

Figure 1 (right panel) shows a performance comparison of CuPy, Numba, and CUDA C for the 1D MCRT problem. In terms of the total execution time (solid lines), for loads $N<{10}^8$, CuPy outperformed Numba and CUDA C. At $N={10}^6$, the difference in performance reached ∼4.72x and ∼3.06x, respectively. As the workload increased ($N>{10}^8$), CUDA C became faster. For $N=2\times {10}^9$, CUDA C was faster by 5.78x and 5.24x as compared to Numba and CuPy. When comparing GPU kernels (dashed lines), CuPy was slower than both Numba and CUDA C. Specifically, it was already 8.5 times slower than CUDA C for $N={10}^4$, and the difference reached 14.2x for $N=2\times {10}^9$. However, Numba demonstrated competitive performance with CUDA C. The slowdown was only 1.53x at $N=2\times {10}^9$. We found that this was mainly caused by two factors: (1) the difference in PRN algorithms used in these two platforms (cf. Section 2); (2) the log function is executed in double precision (cf. Section 3.3). If we used the same PRNG, the difference between Numba and CUDA C became negligible for this test.

The similar performances of Numba and CUDA C for the 1D MCRT problem and their drastic differences in the PRN generation problem point to the reason behind this behavior. In the former problem, where Numba performed relatively slowly, the PRN values are stored in the GPU global memory. In the 1D MCRT problem, PRNs are generated and then used locally. Thus, Numba’s performance was fast (slow) when small (large) data movement was involved [39].

The faster execution time for lower loads (up to $N\le {10}^8$) exhibited by CuPy in the 1D MCRT test can be attributed to the utilization of memory spaces by reserving memory blocks [15]. This reduces the overheads associated with memory allocation and CPU/GPU synchronization due to the “caching” of allocated memory blocks. Since the 1D MCRT problem involves numerous memory allocations, CuPy achieved better overall performance compared to Numba and CUDA C for $N\le {10}^8$. However, in GPU kernel time, CuPy’s performance was slower due to the temporary storing of the calculated values in the global memory after each calculation.

3.1. Impact of Precision

In this section, we study the impact of precision by performing computations in single and double precision. For a similar investigation in the context of the finite-difference approach to Burgers’ equation, see [81]. Extensive tests of Numba and CUDA C for matrix–matrix multiplication, parallel reduction, and 3D stencil application in single and double precisions can be found in [39].

Figure 2 (left panel) shows the GPU kernel execution time for the PRN generation problem using CuPy, Numba, and CUDA C for single and double precisions, as a function of N. As expected, the CUDA C single-precision calculations were faster than the double-precision calculations. The performance difference reached 1.17x at $N={10}^6$. As N increased, the gap widened, reaching 1.77x at $N=2\times {10}^9$. These results are in line with those of previous studies on the impact of precision for CUDA C [87,88]. The same performance pattern was observed in CuPy. This was expected behavior since its PRN generation is based on CUDA’s cuRAND library [15,89].

For Numba, the single precision was slower for $N\le 6\times {10}^7$ and faster for larger N by about ∼12.5%. The reason for this behavior is a combination of two competing factors. On the one hand, Numba generates PRNs in double precision by default (this can be established by analyzing the Nsight Systems profiling tool and examining the PTX assembly code). Conversion to single precision is then performed, introducing an additional overhead. On the other hand, it is faster to write single-precision values to the global memory than double-precision variables. For this reason, single-precision calculations become competitive with (and faster than) double-precision calculations for large N.

Figure 2 (right panel) shows the execution time of the GPU kernel for the single- and double-precision 1D MCRT test problem as a function of N. For CuPy, we observed a similar performance in both precisions up to $N={10}^6$. For larger N, the performance difference only reached 1.43x at $N={10}^9$. This small difference is explained by excessive data movement to/from the global memory for temporary storage after each calculation.

In the case of Numba, the double precision was slower than the single precision for all values of N. Numba converts the double-precision PRN to a single-precision PRN, but unlike CuPy, it does this operation without temporarily storing the data in the global memory after each calculation, which is more efficient. For example, for $N={10}^4$, the difference between the two precisions was 1.08x, while for $N=2\times {10}^9$, the difference rose to 2.74x.

3.2. Energy Consumption

Table 2. Average energy per particle, power usage, and GPU utilization. The values were obtained by generating ${10}^9$ PRNs for the PRN generation test and by tracking ${10}^9$ particles for the 1D MCRT test using the A100 GPU card. See Section 2 for details of the measurement method.

	PRN Generation				1D MCRT
	Energy per PRN [Nanojoule]	Power [Watt]	Util [%]		Energy per Particle [Nanojoule]	Power [Watt]	Util [%]
CuPy	2.82	206	100		22.1	221	100
Numba	2.46	81	100		15.9	68	10
CUDA C	1.17	76	100		4.34	125	46

shows the average energy spent to generate a single PRN (or to track a single particle in the 1D MCRT problem), the power consumption, and GPU utilization. These results were obtained for $N={10}^9$ for the A100 card. We can see that Numba was more energy efficient than CuPy. However, CUDA C was more efficient than both Numba and CuPy. For the PRN generation test, CUDA C spent less energy per PRN than Numba and CuPy by a factor of 2.1 and 2.4, respectively. In the case of 1D MCRT, CUDA C spent less energy by approximately 3.7x than Numba and 5.1x than CuPy. CUDA C is energy efficient compared to Numba and CuPy due to its optimization for the GPU architecture and the efficient utilization of parallel computing capabilities. The optimized utilization of GPU resources minimizes idle times, allowing CUDA C to accomplish more computations per unit of energy. Unlike CUDA C, Numba and CuPy, being just-in-time frameworks for Python, introduce additional overheads and limitations that impact energy efficiency.

In terms of power consumption, CUDA C used 7% less power than Numba and 171% less power than CuPy in the PRN generation test. However, for the 1D MCRT problem (see Table 2), Numba used less power by 84% and 225% than CUDA C and CuPy, respectively. This is attributed to the fact that Numba utilizes the GPU to a lesser extent than CUDA C. For Numba, the PRNG state setup takes place on the host CPU, which is then transferred to the GPU. The wait times associated with this transfer limit the GPU utilization. The high power consumption of CuPy can be explained by excessive data movement [90] due to automatic memory management [15]. The power consumption variations among CuPy, Numba, and CUDA C have implications for practical applications. CUDA C’s emphasis on GPU parallelization and optimization generally leads to higher computational performance and energy efficiency, making it well-suited for applications with time-sensitive results and power constraints [91,92]. Numba and CuPy, while providing relatively easy implementation of GPU applications, introduce overheads that impact performance, and their scalability and energy efficiency are comparatively lower.

3.3. Comparison of GPU Cards

In this section, we compare the performance of three GPU cards using the 1D MCRT test problem. For a similar comparison in the context of PRN generation in CUDA C, see, e.g., [93].

Figure 3 (left panel) shows the execution time for Numba. The PTX assembly code of Numba reveals that, despite explicit specification of all variables and constants as single-precision type, the log function is executed in double precision. This introduces overheads for the RTX3080 GPU card, which can perform double-precision operations 64 times slower than in single precision. For the A100 and V100, the ratio is 1:2 (see Table 1). Consequently, Numba was far slower on RTX3080 than on A100 and V100. The performance gap reached ∼6.7x for $N=2\times {10}^9$ particles.

Figure 3 (right panel) shows the results for CuPy. For $N<3\times {10}^6$, CuPy on RTX3080 and V100 performed faster than on A100. However, at $N\ge 3\times {10}^6$, A100 was faster than V100 and RTX3080, reaching speed-ups of 1.49x and 1.72x for $N={10}^8$, respectively. The slower performance of CuPy on RTX3080 for $N\ge 3\times {10}^6$ is caused by the memory bandwidth, which is less than on A100 and V100 by 105% and 18%, respectively. The better performance of the A100 compared to the V100 at $N\ge 3\times {10}^6$ can also be attributed to the higher memory bandwidth of A100, i.e., by 73% (see Table 1). In the context of CuPy, this factor significantly contributes to the overall performance.

Table 3. Power consumption while generating ${10}^9$ PRNs in the PRN generation problem and tracking ${10}^9$ particles in the 1D MCRT problem for the A100, V100, and RTX3080 GPU cards.

	PRN Generation [Watt]				1D MCRT [Watt]
	A100	V100	RTX3080		A100	V100	RTX3080
CuPy	206	211	293		221	229	297
Numba	81	145	174		68	85	133
CUDA C	76	85	129		141	200	225

shows the power consumption of three GPU cards for the PRN generation and 1D MCRT test problems. The A100 GPU card used less power than V100, which, in turn, used less power than RTX3080. For example, in CUDA C, A100 consumed less power than V100 and RTX3080 by an average of 26.8% and 64.7%, respectively. In the context of Numba, A100 was more efficient by an average of 52% than V100 and 105.2% than RTX3080. For CuPy, A100 used less power by an average of 3% and 38.3% than V100 and RTX3080, respectively.

4. Discussion

Our research work evaluates the performance of GPU programming platforms, specifically CuPy and Numba, within the context of MCRT. By addressing two distinct test problems and comparing outcomes with the CUDA C implementation, we highlight trade-offs between performance and ease of implementation across these platforms. We explored variations in performance for a comprehensive set of test problems, ranging from memory intensive to compute intensive tasks. We also looked at the impact of the precision by considering calculations in single and double precision (see Section 3.1 for more details). Further evaluations involved comparing the performance of various NVIDIA GPU cards. Conducting these comparisons helped us to gain a better understanding of how efficiently each platform performs across different hardware configurations (see Section 3.3). The limitations that we identify suggest avenues for future research. In addition, our findings can serve as a guide for choosing various computational methods for more complicated simulations covering multiple spatial dimensions and complex geometries. Our study contributes valuable insights concerning the strengths and limitations of the GPU programming platforms CuPy and Numba, helping researchers make decisions for optimal performance in MCRT simulations.

5. Conclusions

We investigated the performance of two prominent GPU programming platforms, CuPy and Numba, in the context of the Monte Carlo (MC) radiation transport problem. We considered two idealized test problems. In the first problem, we performed random number generation with subsequent storage of the numbers in the global memory. This problem represented the scenario with heavy memory usage. In the second problem, we considered a one-dimensional MC radiation transport test in a purely absorbing medium. We compared the results to our implementation in CUDA C. We considered three different cards: NVIDIA Telsa A100, Tesla V100, and GeForce RTX3080.

The results show that, overall, CUDA C had the fastest performance and highest energy efficiency. However, Numba demonstrated competitive performance to CUDA C when the data movement was small. In contrast, when data movement was heavy (e.g., storing PRNs in the global memory), Numba was significantly slower than CUDA C. CuPy showed better performance than Numba in the PRN generation test problem due to its efficient memory allocation. However, for compute-heavy tasks (in the case of the 1D MCRT test problem), it lagged behind these platforms substantially. Also, it showed less energy efficiency. The slower performance of CuPy was somewhat compensated by the relative ease of implementation within this platform. These outcomes highlighted the trade-offs between performance and ease of implementation across the programming platforms considered in this work.

The main limitation of our work was that we used an idealized 1D MC radiation transport test in a purely absorbing and static medium. Realistic calculations often take place in multiple spatial dimensions. In general, matter can be non-static. In addition to absorption, matter can emit and scatter radiation. Such scenarios will be considered in future work. Moreover, other platforms that enable GPU computing within the Python language will also be considered. Multiple GPU configurations and GPUs from other vendors will also be explored.