## 5 Results
### Optimization Results  
In order to understand the impact of thread binding and affinity, we present the different elapsed times of GRICS with different configurations using only OpenMP. The elapsed time of the code is insensitive to the variable OMP_PLACES. Hence, we choose to  
Figure 12: Roofline analysis of \(E^{H}E\) on NVIDIA A100. Figure 13: Performance throughputs on RTX 5000 and A100. On GPUs, the main memory system is used optimally, and the achieved throughputs are 90% and 89% for RTX 5000 and A100, respectively. The first difference concerns the L2 cache throughput, 22% for RTX 5000 and 92% for A100. However, the main hardware limitation is the SM utilization; the throughputs are low on both architectures. bind the threads to hardware threads. However, the elapsed time is remarkably sensitive to the binding strategy. * OS OMP: Only OpenMP parallelization over the receiver coils is considered, with basic optimization flags and without thread binding. The GNU C++ compiler is considered. * Close OMP: The thread affinity is enabled with the _close_ option. * Spread OMP: The thread affinity is enabled with the _spread_ option. In the three cases, the compilation flags discussed in Section 4.4.1 are enabled. Each OpenMP configuration for each dataset is executed five times; the reported time is the mean of the five experiments. Since we are the only user at the workstation while conducting the testing, the differences in the execution times between multiple runs (for a given binding strategy) are not significant: the standard deviations range from 0.30 s to 1.001 s. The thread binding and compilation flags do not impact the numerical accuracy and stability of the program since the number of conjugate gradient iterations remain the same with spread/close bindings: 4, 5, 4, and 11 iterations, respectively, for \(D_{1},D_{2},D_{3}\), and \(D_{4}\). Moreover, we compute the Normalized Root Mean Square Error to prove that there is no image quality degradation with the proposed optimizations: \(I_{1},I_{2}\), and \(I_{3}\) stand, respectively, for the reconstructed images with the spread, close, and no binding options; we calculate max(NRMSE(\(I_{1},I_{2}\)), NRMSE(\(I_{1},I_{3}\)), and NRMSE(\(I_{2},I_{3}\))). These values are, respectively, equal to \(4.67\times 10^{-7},5.95\times 10^{-7}\), \(4.89\times 10^{-7}\), and \(2.40\times 10^{-3}\) for \(D_{1},D_{2},D_{3}\), and \(D_{4}\). Thread binding and affinity decisions (spread or close) are architecture-dependent for the same program. Using Table 6, we can see that, on the AMD EPYC processor, the _spread_ option enables a gain of 9-17% on the AMD EPYC CPU, while the _close_ option degrades the performance compared to the OS allocation. On the Intel CPU, the code is much slower, and the _close_ option yields better results compared to the _spread_ binding. However, the OS thread allocation is more suitable to the GRICS on this architecture. The roofline analysis and the performance of the GRICS's OpenMP version prove that the EPYC CPU is more suitable for the code, notably in terms of its demanding data traffic. The high value of EPYC's DRAM bandwidth accelerates the rate at which the data are transferred to the compute units and enables rapid execution. For these reasons, we decided to investigate the performance of the hybrid version only on the AMD EPYC CPU; the different execution times are presented in Figure 14. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**OpenMP Option** & **Dataset** & **GRICS EPYC (s)** & **GRICS Xeon (s)** \\ \hline \multirow{3}{*}{OS OMP} & \(D_{1}\) & 214 & **485** \\  & \(D_{2}\) & 294 & **587** \\  & \(D_{3}\) & 293 & **614** \\  & \(D_{4}\) & 225 & **500** \\ \hline \multirow{3}{*}{Close OMP} & \(D_{1}\) & 272 & 526 \\  & \(D_{2}\) & 376 & 630 \\  & \(D_{3}\) & 416 & 657 \\  & \(D_{4}\) & 256 & 520 \\ \hline \multirow{3}{*}{Spread OMP} & \(D_{1}\) & **190** & 550 \\  & \(D_{2}\) & **259** & 658 \\ \cline{1-1}  & \(D_{3}\) & **267** & 683 \\ \cline{1-1}  & \(D_{4}\) & **186** & 545 \\ \hline \hline \end{tabular}
\end{table}