## 5 Results  
### Performance Analysis  
The CPU roofline models are presented below. We used dataset \(D_{1}\). The main difference between the two CPUs is the DRAM bandwidth. For the Intel Xeon processor, the memory bandwidth is equal to 70.3 GB/s, and, for the AMD EPYC processor, it is equal to 221.1 GB/s. Regarding the Floating Point performance, Intel Xeon has the lead with a \(P_{m}=1544\) GFLOP/s. However, since the GRICS reconstruction relies on repeated FFT, the code will likely be impacted by the memory bandwidth, and efforts should be undertaken in this direction to optimize the code. Intel SDE and Vtune report that the GRICS's operational intensity \(I_{DRAM,Xeon}\) is equal to 0.8 FLOP/byte. AMD\(\mu\)Prof reports that \(I_{DRAM,EPYC}=0.69\) FLOP/byte. Using Figures 8 and 9, we can see that, in both architectures, the GRICS is memory bound. In Intel Xeon, the code is mainly limited by the low value of the DRAM bandwidth; its actual performance \(P_{Xeon}\) is equal to 16 GFLOP/s. \(P_{Xeon}\) is far from the theoretical bound for this value of operational intensity; a code that has a similar value of \(I_{DRAM,Xeon}\) and that uses the micro-architecture of the processor in a better way can operate at a performance \(P_{mXeon}\) equal to 56 GFLOP/s. Using Equation (4), the code's architectural efficiency on Xeon is 28%. On the AMD EPYC CPU, it performs better, with a performance \(P_{AMD}\) equal to 80 GFLOP/s. In this architecture, the code benefits from the high value of the memory bandwidth, \(B_{s}=221.1\) GB/s. Its architectural efficiency on EPYC is 52%. Moreover, the figures show that \(I_{I2,Xeon}\approx I_{I3,Xeon}\approx I_{DRAM,Xeon}\), which means that there is poor data reuse; once the data are loaded from the main memory, they are not reused while being in caches and instead evicted. This is not the case regarding the AMD EPYC CPU, where \(I_{DRAM,EPYC}\) is greater than \(I_{L3,Xeon}\) and \(I_{L2,Xeon}\), which means that the data are being reused once they are loaded from DRAM. Figure 10 presents the computational and memory complexity of Algorithm 2 as a function of the elapsed time per iteration on the AMD EPYC CPU. The complexities are computed using Equations (7) and (8). Datasets \(D_{3}\) and \(D_{4}\) align closely with the predicted trend, both for memory and computation. \(D_{2}\) lies above the linear fitting lines, suggesting lower computational and memory efficiency than expected. \(D_{1}\) shows both good memory and computational efficiency, positioned below the fitting lines. Figure 8: Roofline analysis of GRICS on Intel Xeon Gold. Figure 9: Roofline analysis of GRICS on AMD EPYC. Figures 11 and 12 present the GPU roofline models. In both architectures, the reconstruction kernel is compute bound. The kernel's performance on RTX 5000 \(P_{RTX}\) is equal to 5 GFLOP/s, while its performance on A100, \(P_{A100}\), is equal to 16 GFLOP/s. In both cases, the actual performance is far from the roofline boundaries, which means that the actual implementation does not properly use the GPU architecture and that source-code modifications should be considered in order to achieve better performance. Moreover, we notice the absence of data reuse on Quadro RTX, \(I_{DDR,RTX}\approx I_{L2,RTX}\), which means that there are repetitive calls to the main memory in order to satisfy the load and store operations. However, the data are being reused on A100, which reduces the latency and improves the overall performance of the kernel. The A100 GPU has 40 MB of L2 cache, which is 10 times larger than Quadro's L2 cache. The increase in the L2 cache size improves the performance of the workloads since larger portions of datasets can be cached and repeatedly accessed at a much higher speed than reading from and writing to HBM memory, especially the workloads that require a considerable memory bandwidth and memory traffic, which is the case for this kernel.