# A Novel GPU-Based Acceleration Algorithm for a Longwave Radiative Transfer Model
## 5 Algorithm Implementation
### trrnmc_d
For exploring whether/how the number of threads in a thread block may affect the computation performance, the execution time of the G-RRTMG_LW with a tuned number of threads was measured over one GPU. Taking the case of no I/O transfer as an example, Figure 5 portrays the runtime of the G-RRTMG_LW on one K20 GPU. Indeed, the number of threads per block, or block size, affected the computation performance to some extent. The G-RRTMG_LW achieved optimal performance when the block size was 128. The G-RRTMG_LW on one K40 GPU resulted in a similar rule, as shown in Figure 6. Some conclusions and analysis are drawn as below. 1. Generally, increasing the block size can hide some memory access latency to some extent and improve the computational performance of parallel algorithms. Therefore, kernels with simple computation usually show optimal performance when the block size is 128 or 256. Thus, with a large amount of calculation, the kernel \(taumol\) with an acceleration in the \(g\)-\(point\) dimension achieved optimal performance on one K20 GPU when the block size was 128. 2. The runtime and speedup of the RRTMG_LW 2D acceleration algorithm on the K20 and K40 GPUs are shown in Table 2. From Table 2, Figures 5 and 6, the kernel \(taumol\) with an acceleration in the \(g\)-\(point\) dimension costs more computational time than its 2D version did. This is because there is much redundant computing in the current \(taumol\). For example, each thread in 2D \(taumol\) \begin{table}
\begin{tabular}{c c c} \hline \hline
**Specification of CPU** & **K20 Cluster** & **K40 Cluster** \\ \hline CPU & E5-2680 [EMAIL_ADDRESS] GHz & E5-2695 [EMAIL_ADDRESS] GHz \\ Operating System & CentOS 6.4 & Red Hat Enterprise Linux Server 7.1 \\ \hline
**Specification of GPU** & **K20 Cluster** & **K40 Cluster** \\ \hline GPU & Tesla K20 & Tesla K40 \\ CUDA Cores & 2496 & 2880 \\ Standard Memory & 5 GB & 12 GB \\ Memory Bandwidth & 208 GB/s & 288 GB/s \\ CUDA Version & 6.5 & 9.0 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Configurations of GPU clusters. ran the code shown in Table 3, but each thread in the current \(taumol\) still had to run the code although there were more threads. Therefore, the current \(taumol\), with more threads than its 2D counterpart, did not take full advantage of having plenty of threads. 3. The \(rtrnmc\) with an acceleration in the \(g\)-\(point\) dimension on one K20 GPU and one K40 GPU both achieved optimal performance when the block size was 512. During its current acceleration, more threads were assigned, so that each thread had fewer calculations and required fewer hardware resources. When the block size was 512, the assigned hardware resources of each thread were in a state of equilibrium, so in this case, the current \(rtrnmc\) showed better performance. Figure 5: Runtime of the G-RRTMG_LW on one K20 GPU. Figure 6: Runtime of the G-RRTMG_LW on one K40 GPU. ### Evaluations on Different GPUs

The runtime and speedup of the G-RRTMG_LW on the K20 and K40 GPUs are shown in Table 4. Due to the poor performance of the _taumol_ with an acceleration in the _g-point_ dimension, its 2D version was still used here. The speedups of the _inatm_ and _rtrnmc_ with an acceleration in the _g-point_ dimension on one K20 GPU were 87.37\(\times\) and 13.20\(\times\), respectively. Using one K20 GPU in the case without I/O transfer, the G-RRTMG_LW achieved a speedup of 25.47\(\times\) as compared to its counterpart running on one CPU core of an Intel Xeon E5-2680 v2. Whereas, using one K40 GPU in the case without I/O transfer, the G-RRTMG_LW achieved a speedup of 30.98\(\times\). Some conclusions and analysis are drawn below. 1. The K40 GPU had a higher core clock and memory clock, more cores, and stronger floating-point computation power than the K20 GPU did. Thus, the G-RRTMG_LW on the K40 GPU showed better performance. 2. According to the testing, it was found that the transposition of four 3D arrays in the 1D or 2D _inatm_ required most of the computational time.