## 5 Results
### Optimization Results

Table 6: Elapsed time of GRICS with different OpenMP configurations on CPUs. The GRICS's hybrid implementation improves the overall performance in terms of elapsed time. The best performances are achieved when the number of MPI processes \(n\) divides the number of motions states \(N_{t}\); for datasets \(D_{1},D_{2}\), and \(D_{3}\), \(N_{t}\) is equal to 12 and the minimal times are reported for \(n\in\{3,4,6\}\). The best performance is achieved with \(n=6\) ranks. For dataset \(D_{4}\) with \(N_{t}=16\), the minimal elapsed time corresponds to the \(n=4\) and \(n=8\) processes. When the number of processes \(n\) divides the number of motion states \(N_{t}\) evenly, it leads to better load balancing. Each process receives an equal share of the workload, minimizing idle times. The empirical data show that the elapsed time initially decreases with increasing processes (up to a certain point) and then starts increasing. More processes may increase the number of communications required, leading to higher network traffic and contention. For the OpenMP parallelization of the loop over the \(N_{c}\) coils, choosing a number of threads \(m\) such that \(m\) divides \(N_{c}\) does not greatly improve the overall performance; the set of threads \(m\) when \(m\in\{10,12,13,15,18,20\}\) provides approximately the same result. A small improvement is noticed when \(m=N_{c}/2\). The best MPI OpenMP settings are \(n=N_{t}/2\) and \(m=N_{c}/2\) for all the datasets. Finally, we present in Table 7 a performance-based comparison between the CPUs and GPUs for the reconstruction kernel. The reported times correspond to the best parallelization strategy for each device; we use dataset \(D_{1}\). There is no significant difference between the MRI images from the CPUs and GPUs. Setting \(I_{CPU}\) and \(I_{GPU}\) as the reconstructed images using the CPU and GPU, respectively, the Normalized Root Mean Square Error of the two images, \(\text{NRMSE}(I_{CPU},I_{GPU})\), is equal to \(10^{-5}\), which is less than the tolerance of the reconstruction solver (\(10^{-3}\)). From an architectural perspective, the kernel and GRICS operate well on an AMD EPYC CPU. The roofline analysis on the A100 GPU and the kernel's elapsed time on this architecture provide us insights about the possible benefits of a full GPU implementation of the GRICS. Even if the actual one is not \"GPU architecture aware\", its result is promising. On Quadro RTX5000, the code is slower; Nsight compute reports that L2-DDR data transfer is one of the bottlenecks on this GPU. However, the main hardware limitation on GPUs is the SM's poor utilization. Both devices offer sophisticated compute capabilities with Tensor cores and CUDA cores, but the actual implementation is not adapted to using the GPU architecture properly, which is why the overall performance values, \(P_{RTX}\) and \(P_{A100}\), are  
Figure 14: Elapsed time of GRICS for different MPI processes on AMD EPYC; the number of OpenMP threads was fixed to 20. The reported times are the mean of 5 executions. The maximum standard deviations were 0.96, 0.14, 0.39, and 0.13 for \(D_{1}\), \(D_{2}\), \(D_{3}\), and \(D_{4}\), respectively. We highlighted the best times per dataset in red. low compared to \(P_{AMD}\). On the Intel Xeon Gold CPU, the code is mainly limited by the low value of memory bandwidth, absence of data reuse, and absence of vectorization.