## 6 Discussion  
Using the proposed optimizations renders GRICS reconstruction available at the MRI console within an acceptable delay (80-102 s depending on the dataset), even in the case of very high-resolution 3D images. This delay is smaller than the typical acquisition time for one sequence of the examination. This is important for clinical use as the radiologist needs to visualize the images shortly after scanning, evaluate whether the image quality is sufficient for diagnostic use, and decide whether the patient can be released from the scanner. The optimal processor architecture is algorithm-dependent, and the roofline model is a visual model that helps in evaluating the software-hardware interaction. It is difficult to suggest a parallelization strategy that would be beneficial to every architecture or to confirm that an optimization pattern would improve the performance on multiple architectures. However, in this work, we presented steps to follow in order to evaluate the actual performance of a program, and ways to improve it with no source-code modification, by establishing the roofline model of the considered workstation using performance profiling tools to generate the operational intensity of the code and performing a roofline analysis to capture the hardware limitations and bottlenecks. In this work, we determined the main hardware limitations of the iterative MRI reconstruction algorithms, which are not straightforward to estimate, depending on the workstation (CPUs or GPUs). For the CPU optimizations, we suggested to identify the appropriate compilation flags for the architecture, to test several binding strategies for the OpenMP parallelization, and to select the optimal number of MPI ranks to minimize the communication overhead and ensure effective parallelization. We have shown that, without any code modification, using thread binding and affinity enables gains of 11%, 12%, 9%, and 17% for \(D_{1}\), \(D_{2}\), \(D_{3}\), and \(D_{4}\), respectively, with only OpenMP on AMD EPYC. The GRICS's architectural efficiency on this CPU is equal to 52%. However, the OS OpenMP affinity provides better results when it comes to Intel Xeon compared to the _spread_ and _close_ options. On this CPU, the code's architectural efficiency is 28%. The optimal MPI and OpenMP combination yields gains of 62%, 65%, 68%, and 62% for \(D_{1},D_{2}\), \(D_{3}\), and \(D_{4}\), respectively, on AMD EPYC. These gains are computed relative to the OS OpenMP elapsed time for each dataset. The reconstruction kernel's elapsed time on the A100 GPU was the lowest, even if the roofline analysis pointed out that the GPU architecture is not optimally used. A low execution time does not guarantee an optimal GPU utilization. Figure 13 shows that the GPU memory bandwidth is used efficiently. However, the program is not fully utilizing the GPU's available cores, leading to a suboptimal performance. For instance, using only a fraction of the available cores will leave the rest of the GPU's resources idle (low SM throughput on both devices) and lead to an imbalanced workload among the threads. Optimal GPU utilization requires a program to effectively leverage the parallelism, memory bandwidth, load balancing, and \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Device** & \(B_{s}\) **(GB/s)** & \(P_{m}\) **(GFLOP/s)** & \(P\) **(GFLOP/s)** & \(T\) **(s)** & **Bound** \\ \hline EPYC & 221.1 & 1348 & 80 & 56 & Memory \\ Xeon Gold & 70.3 & 1544 & 16 & 425 & Memory \\ RTX 5000 & 281.5 & 6828.8 & 5 & 145 & Compute \\ A100 & 1227.7 & 12,526.1 & 16 & 33 & Compute \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Performance comparison of CPU/GPU. On CPUs, \(P\) stands for the performance of GRICS, while it stands for the reconstruction kernel’s performance on GPUs. However, both performances can be compared since the reconstruction kernel represents 70–80% of the GRICS’s elapsed time. The kernel’s performance on the CPU would be close to the GRICS’s performance on CPU. \(T\) is the elapsed time of the kernel.