AMD-powered Frontier supercomputer breaks the exascale barrier

171–172 of 172 posts

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#171

Post by JonChesterfield » Sun, Jun 05, 2022, 11:14 AM UTC

dragontamer wrote: post #140

slavik81 wrote: post #135

Earlier quoted context omitted.

Navi 21 launched in November 2020 but it only got official support with ROCm 5.0 in February 2022. With respect to your issue running 1024 threads per block, if you're running out of VGPRs, you may want to try explicitly specify the max threads per block as 1024 and see if that helps. I recall that at one point the compiler was defaulting to 256 despite the default being documented as 1024.

The main issue I have with the idea of Navi 21 is that its a 32-wide warp, when CDNA2 (like MX250x) is 64-wide warp. Granted, RDNA and CDNA still have largely the same assembly language, so its still better than using say... NVidia GPUs. But I have to imagine that the 32-wide vs 64-wide difference is big in some use cases. In particular: low-level programs that use warp-level primitives, like DPP, shared-memory detai…

The radeon vii was a great choice for that while it was on sale. I'm going to be quite sad when mine die.

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#172

Post by JonChesterfield » Sun, Jun 05, 2022, 11:24 AM UTC

guenthert wrote: post #100

Const-me wrote: post #90

Earlier quoted context omitted.

> The former are useless for DP computations Looking at “double-precision GFlops” columns there [1] they don’t seem terribly bad, more than twice as fast compared to similar nVidia chips [2] While specialized extremely expensive GPUs from both vendors are way faster with many TFlops of FP64 compute throughput, I wouldn’t call high-end consumer GPUs useless for FP64 workloads. The compute speed is not terribly bad, an…

SP is sixteen times the performance of DP here for no other reasons then market segmentation. Nvidia might have started that, but that's no reason not to call AMD out for it.

fp32 uses much less silicon and power than fp64. I think the scaling is roughly quadratic in both, so 4x performance is free.

I vaguely remember a consumer card having 1/4 the fp64 units of a similar data center one so that would get the 16x on paper.

Memory bandwidth / register file size would suggest another 2x from moving less data. My working heuristic on these things is compute is free because I fail to saturate the memory bus but no doubt some applications do actually run into that slowdown in practice. Matrix multiply probably does.

Post reply on HN