Live data from Hacker News

AMD-powered Frontier supercomputer breaks the exascale barrier

tomshardware.com

11–20 of 172 posts

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#11
post #5

Earlier quoted context omitted.

I’m not using Frontier, but I am using Setonix which is a large AMD cluster being rolled out in Australia. All of AMD’s teaching materials are about ROCm so this is very much how they’re expecting it to be used. The real pain for us is that there’s no decent consumer grade chips with ROCm compatibility for us to do development on. AMD have made it very clear they only care about the data centre hardware when it comes…

Interesting. So what is your workflow right now?

Develop against CUDA locally. Port my kernels to ROCm, and occupy a whole HPC node for debugging and performance tuning for a week. It’s terrible.

Edit: I should say that their recommendation is to write the kernels in ‘hip’ which is supposed to be their cross device wrapper for both cuda or ROCm. I’m writing in Julia however so that’s not possible.

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#12
post #5

Since they are using AMD's accelerators as well [1], I do wonder whether any usage of these will trickle down and give us improvements in ROCm. Surely the people at these labs will want to run ordinary DL frameworks at some point - or do they have the money and time to always build entirely custom stacks? [1] AMD Instinct MI250x in this case.

I’m not using Frontier, but I am using Setonix which is a large AMD cluster being rolled out in Australia. All of AMD’s teaching materials are about ROCm so this is very much how they’re expecting it to be used. The real pain for us is that there’s no decent consumer grade chips with ROCm compatibility for us to do development on. AMD have made it very clear they only care about the data centre hardware when it comes…

Can you write SYCL code and compile it to ROCm for production?

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#14
post #5

Since they are using AMD's accelerators as well [1], I do wonder whether any usage of these will trickle down and give us improvements in ROCm. Surely the people at these labs will want to run ordinary DL frameworks at some point - or do they have the money and time to always build entirely custom stacks? [1] AMD Instinct MI250x in this case.

I’m not using Frontier, but I am using Setonix which is a large AMD cluster being rolled out in Australia. All of AMD’s teaching materials are about ROCm so this is very much how they’re expecting it to be used. The real pain for us is that there’s no decent consumer grade chips with ROCm compatibility for us to do development on. AMD have made it very clear they only care about the data centre hardware when it comes…

NV21?

https://www.phoronix.com/scan.php?page=news_item&px=Radeon-R...

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#15
post #6

Thank you to the authors for not calling it the fastest computer in the world :-) and instead, as they should, the most powerful. Clock speed is not the only factor of course, as instruction per cycle and cache sizes have an impact, but for a pure measure of speed, the fastest still is: - For practical use, and non overclocked, the EC12 at 5.5 Ghz: https://www.redbooks.ibm.com/redbooks/pdfs/sg248049.pdf or - An AMD F…

> Clock speed

When people talk about a supercomputer being 'fast' they generally mean FLOPS - floating point operations per seconds, which isn't clock-speed.

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#16
post #8

The more powerful processors become, the less I feel there's a need to build supercomputers. Thinking about it, the most powerful supercomputer in the world is pretty much a million consumer processors, working in parallel. That's going to stay pretty constant, since cost scales roughly linearly. If X is the processing power of $1k of consumer hardware, the bigger X gets, the less there is a difference in the class o…

By the way, while cost may scale linearly, the number of cores doesn't[0]. We have more powerful computers in our pockets than Cray supercomputers from the 80s. And I feel we still haven't learned how to use these cores in an efficient way.

[0] https://i.imgur.com/Gad4cKk.png

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#17
post #6

Thank you to the authors for not calling it the fastest computer in the world :-) and instead, as they should, the most powerful. Clock speed is not the only factor of course, as instruction per cycle and cache sizes have an impact, but for a pure measure of speed, the fastest still is: - For practical use, and non overclocked, the EC12 at 5.5 Ghz: https://www.redbooks.ibm.com/redbooks/pdfs/sg248049.pdf or - An AMD F…

Clock rates of CPUs are not a measure of "speed". Time to solution is the measure of speed. There have historically been computers with lower clock rates with higher rates of results production (larger cache, more work done per cycle).

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#18

Since they are using AMD's accelerators as well [1], I do wonder whether any usage of these will trickle down and give us improvements in ROCm. Surely the people at these labs will want to run ordinary DL frameworks at some point - or do they have the money and time to always build entirely custom stacks? [1] AMD Instinct MI250x in this case.

> Surely the people at these labs will want to run ordinary DL frameworks at some point I don't know about that. A lot of these labs are doing physics simulations and are probably happy to stick with their dense-matrix multiply / BLAS routines. Deep learning is a newer thing. These national labs can run them of course, but these national labs have existed for many decades and have plenty of work to do without deep le…

From my limited exposure to the HPC groups at the labs, there's a mixture of languages in use. It seems that modern C++ is the dominant language for a lot of new projects--some of the people I talked to were working on libraries that aggressively used C++11/C++14 features.

The biggest challenge the national labs face is that there's not really any budget (or appetite) to rewrite software to take advantage of hardware features (particularly the GPU-based accelerator that's all the rage nowadays). You might be able to get a code rewritten once, but an era where every major HPC hardware vendor wants you to rewrite your code into their custom language for their custom hardware results in code that will not take advantage of the power of that custom hardware. OpenMP, being already fairly widespread, ends up becoming the easiest avenue to take advantage of that hardware with minimal rewriting of code (tuning a pragma doesn't really count as rewriting).

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#19
post #6

Thank you to the authors for not calling it the fastest computer in the world :-) and instead, as they should, the most powerful. Clock speed is not the only factor of course, as instruction per cycle and cache sizes have an impact, but for a pure measure of speed, the fastest still is: - For practical use, and non overclocked, the EC12 at 5.5 Ghz: https://www.redbooks.ibm.com/redbooks/pdfs/sg248049.pdf or - An AMD F…

Yes the fastest computers are those aboard the Parker Solar Probe at 690,000 km/h.

Re: AMD-powered Frontier supercomputer breaks the exascale barrier

#20

Earlier quoted context omitted.

> Surely the people at these labs will want to run ordinary DL frameworks at some point I don't know about that. A lot of these labs are doing physics simulations and are probably happy to stick with their dense-matrix multiply / BLAS routines. Deep learning is a newer thing. These national labs can run them of course, but these national labs have existed for many decades and have plenty of work to do without deep le…

> Given all the talk about OpenMP compatibility and Fortran... my guess is that they're largely running legacy code in Fortran. The must used linear algebra library is written in Fortran. There's nothing "legacy" about it, it's just that nobody was able to replicate its speed in C.

> The must used linear algebra library is written in Fortran.

My understanding is that most supercomputers have the vendor provide their implementation of BLAS (e.g., if it's Intel-based, you're getting MKL) that's specifically tuned for that hardware. And these implementations stand a decent chance of being written in assembly, not Fortran.

Post reply on HN