First true exascale supercomputer?(top500.org) |
First true exascale supercomputer?(top500.org) |
What's nice about programming GPUs in Julia is that you can write code once and execute it on multiple kinds of GPUs, with excellent performance. The KernelAbstractions.jl library makes this possible for compute kernels by acting as a frontend to AMDGPU.jl, CUDA.jl, and soon Metal.jl and oneAPI.jl, allowing a single piece of code to be portable to AMD, NVIDIA, Intel, and Apple GPUs, and also CPUs. Similarly, the GPUArrays.jl library allows the same behavior for idiomatic array operations, and will automatically dispatch calls to BLAS, FFT, RNG, linear solver, and DNN vendor-provided libraries when appropriate.
I'm personally looking forward to helping researchers get their Julia code up and running on Frontier so that we can push scientific computing to the max!
Library link: <https://github.com/JuliaGPU/AMDGPU.jl>
This seems suprising to me, I would have expected 10Gb at least, if not something like inifiniband.
https://www.hpe.com/us/en/compute/hpc/slingshot-interconnect...
This must include the GPUs, otherwise it'd be 136,408 sockets. For a 42U rack with 4P 1U servers (not that that's what's in use, but to give an understandable napkin figure), that'd be 812 racks.
Frontier's own page says 74 "cabinets"/racks, and this is just for the compute (and perhaps switching and/or power? storage is elsewhere). Made up of 9408 nodes, with 4 MI250X gpu accelerators each- those accelerators being dual chip + 8x HBMe2 memory a piece monsters. From Anandtech[1], we can see the liquid-cooled half-width sleds are dual socket, and packed packed packed.
[1] https://www.anandtech.com/show/17074/amds-instinct-mi250x-re...
This was a governmental report on the challenges of Exascale. Contributors included major universities and all the US supercomputing facilities. It wasn’t that they overlooked the possibility of Moore’s law continuing and associated power reduction.
Just found the article which explains the gains. Mostly GPU. A billion processors doing a billion fips each.
But I think that having no interest in their actual applications has curbed my enthusiasm. I wish I could make a good living in something that interested more.
https://www.usenix.org/conference/atc21/presentation/fri-key...
https://developer.amd.com/resources/rocm-learning-center/fun....
My experience is that the stack is pretty rough around the edges. But when it works, you (almost) literally find-and-replace, and it pretty much works as advertised. However, just because you can get to a correct code doesn't necessarily mean that code will achieve optimal performance (without further tuning, of course).
I'm pretty bullish on the long term survival of Linux in some form or other, proprietary OS's not so much.
So, it's not actually the first one? And another one already exists outside the US?
Interestingly, the second one is 30 MW.
EDIT: Wikipedia also says Roadrunner was not considered power-efficient in its day, which led to it being decommissioned after only five years of operation.
Wondering if they measure while benchmarking, or add up max power ratings of the chips.
Did any old mainframe ever burn like that? E.g. the first big USAF missile tracking system, the one that filled four floors of a custom building?
(498 kW for 229 GFlops. 136,317 times more power draw per flops than the current leader on the Green500.)
Lego style supercomputers are still very interesting in my eye though. As the technical complexity involved in scaling the raw compute performance has simplified to a "how many do you want" problem the technical complexity in the interconnects has remained interesting and innovative both for connectivity intra and inter node. You won't really see that in the FLOPS number that makes the headlines but the interconnect can be the difference between a type of workload being feasible or not. The main push here is how large you can make certain levels of shared memory access happen at what latencies to run larger jobs instead of just more jobs.
However the second-fastest (ARM based Fugaku) absolutely wipes the floor with the fastest in certain tasks due to a difference in interconnect topology. Fugaku futhermore has no GPUs unlike many other super computers and instead a CPU with some vector instructions, leading to a different programming model.
If you are more into specialized hardware, Anton3 is amazing.
That's the Cloud, not supercomputing. Supercomputing is all about interconnect.
https://longnow.org/essays/richard-feynman-connection-machin...
Besides which, at that level the goal is not to go "look at this cool thing we built", it's more like "how do we cheaply and effectively build something that can solve these massive weather/nuclear explosion/human brain/etc. simulation problems we have?" and if ganging together lots of off-the-shelf CPUs/GPUs achieves that goal with less time, effort, and cost than building super-custom, boutique-schmoutique hardware, so be it.
Said that, #1 is about twice as fast as #2, which is about three times as fast as number #3. Those gaps are much wider then I would have expected this late in the game.
https://news.ycombinator.com/item?id=9349116 (2015, 93 comments)
https://news.ycombinator.com/item?id=26740371 (2021, 151 comments) etc.
That said, each of the nodes is itself composed of multiple cores with shared memory. So in cases where you really want to grind out performance, you actually end up using message passing to divvy up chunks of work, and then use classic pthreads to parallelize things further, with lower latency.
I forget the exact terminology used, but the parent is right that the interconnect is the "killer feature." To make that message passing fast, there's a lot of crazy topography to keep the number of hops down. The Q had nodes connected in a "torus" configuration to that end [1].
Debugging is a bit of a nightmare, though, since some bugs inevitably only come up once you have a large number of nodes running the algorithm in parallel. But you'll probably be in a mainframe-style time-sharing setup, so you may have to wait hours or more to rerun things.
This applies less to some of the newer supercomputers, which are more or less clusters of GPUs instead of clusters of CPUs. I imagine there's some commonality, but I haven't worked with any of them so I can't really say.
[1] https://www.scorec.rpi.edu/~shephard/FEP19/notes-2019/Introd...