Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

nextplatform.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#31

Post by dragontamer »

volta83 wrote: post #12

I wonder how they manage to keep the FP64 units busy. Seems this is an HPC product, but many HPC apps are memory bound. So to improve FP64 perf by 4 one might need to improve DRAM bandwidth by 8-16x. Otherwise the units would only be stalled waiting for memory. But it seems they did not improve bandwidth by much?

> Seems this is an HPC product, but many HPC apps are memory bound.

The point of a supercomputer is to throw so much compute at a problem, that everything else is the bottleneck.

If an HPC app is memory-bound, then the GPU / Supercomputer was successful at its job. So many HPC apps are memory bound because... well... turns out our machines are actually quite good.

In any case, MI200 has 1.6x the bandwidth as the A100. So if you have a massively-parallel use-case that is memory bound, the MI200 line should have an advantage.

-------

The main issue IMO, is that the MI200's 1.6x bandwidth is really 80% bandwidth applied over two die, connected with a incredible amount of "infinity fabric" links to share the data. I have to imagine that the A100's larger design wins in some cases over the MI200's chiplet design.

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#32

Post by diamondlovesyou »

dragontamer wrote: post #28
cnschn wrote: post #22

Earlier quoted context omitted.

Just curious, what lower level options are there? Inline assembly in OpenCL?

I never touched it myself, but AMD once exposed the "HSA" interface, which is the AMD GPU execution engine. ROCm / HIP and OpenCL are built on top of that HSA level. I don't think any docs exist for it, but you can see a ton of references to HSA stuff if you browse the ROCm source code. -------- It sounds like the parent post discusses details about how AMD GPUs "pick" the next kernel to run. I've been told that the…

Correct; Rocm/HIP/OpenCL are all built on HSA APIs, with a few AMD specific extensions.

AMDGPU's command processor is exposed to you (the CP is what invokes "kernels" GPU side): create signals (essentially just an atomic u64 in host memory, with a few extra bells and whistles to support interrupts) and use those in one of the barrier packet types in a HSA device queue. With these (with one sad caveat that work packets can't have deps themselves :( ) you can enqueue most computation graphs and the CP will handle waiting for signals without any CPU involvement. Plus, GPU kernels can also concurrently write to this queue (though you can't create signals GPU side...)

AMDGPUs are like shared memory machines, which I think is really cool.

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#33

Post by diamondlovesyou »

cnschn wrote: post #22
diamondlovesyou wrote: post #7

Earlier quoted context omitted.

Machine learning isn't the only useful thing to run on "GPU"s (these can't do graphics workloads anymore; they're basically just vector processors). AMD isn't attempting to complete on f16 perf. They're completing where Nvidia's perf is abysmal: f64. Having programmed AMDGPUs at a lower level than HIP/Rocm, they are actually much better than Nvidia (and in fact I'm able to do cool things like pcie large bar/p2p even…

Just curious, what lower level options are there? Inline assembly in OpenCL?

I use LLVM directly. The LLVM AMDGPU target machine is supported by AMD and they use it internally in HIP/OpenCL.

I don't think OpenCL should be used going forward; it not really platform independent. And SPIR-V... kinda sucks tbh. Plus, where's my single source stuff (a la CUDA)?

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#34

Post by dragontamer »

diamondlovesyou wrote: post #32
dragontamer wrote: post #28

Earlier quoted context omitted.

I never touched it myself, but AMD once exposed the "HSA" interface, which is the AMD GPU execution engine. ROCm / HIP and OpenCL are built on top of that HSA level. I don't think any docs exist for it, but you can see a ton of references to HSA stuff if you browse the ROCm source code. -------- It sounds like the parent post discusses details about how AMD GPUs "pick" the next kernel to run. I've been told that the…

Correct; Rocm/HIP/OpenCL are all built on HSA APIs, with a few AMD specific extensions. AMDGPU's command processor is exposed to you (the CP is what invokes "kernels" GPU side): create signals (essentially just an atomic u64 in host memory, with a few extra bells and whistles to support interrupts) and use those in one of the barrier packet types in a HSA device queue. With these (with one sad caveat that work packet…

> you can enqueue most computation graphs

Can those command graphs loop?

I know this interface is undocumented... but I've had an idea for a GPU-language akin to Java or Lisp memory-management. The gist is that kernel_X() can execute, but may fail in any new() or malloc() command.

In such a case, I'd want the compute-graph to loop: while (kernel_X fails due to out-of-memory){ garbage_collect(); try kernel_X() again}.

-------

Not that I have the time to experiment with something like this, but I guess I've been curious to know if that sort of thing can even work.

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#35

Post by diamondlovesyou »

dragontamer wrote: post #34
diamondlovesyou wrote: post #32

Earlier quoted context omitted.

Correct; Rocm/HIP/OpenCL are all built on HSA APIs, with a few AMD specific extensions. AMDGPU's command processor is exposed to you (the CP is what invokes "kernels" GPU side): create signals (essentially just an atomic u64 in host memory, with a few extra bells and whistles to support interrupts) and use those in one of the barrier packet types in a HSA device queue. With these (with one sad caveat that work packet…

> you can enqueue most computation graphs Can those command graphs loop? I know this interface is undocumented... but I've had an idea for a GPU-language akin to Java or Lisp memory-management. The gist is that kernel_X() can execute, but may fail in any new() or malloc() command. In such a case, I'd want the compute-graph to loop: while (kernel_X fails due to out-of-memory){ garbage_collect(); try kernel_X() again}.…

> Can those command graphs loop?

Not directly (barrier packets wait for 0 only, plus the queue packets aren't preserved), but kernels can write to any dispatch queue themselves, so you can get the same effect at the end of your "loop body".

> I know this interface is undocumented... but I've had an idea for a GPU-language akin to Java or Lisp memory-management. The gist is that kernel_X() can execute, but may fail in any new() or malloc() command.

Memory allocation isn't special and allocators can be layered: you can allocate memory ahead of time and then just run the allocation algorithms GPU side. I wrote a Rust framework which cross compiles code/MIR on demand; you can in theory have a Rust allocator and use it to allocate GPU/CPU memory from either GPU/CPU. The only part the GPU can't do (directly) is invoke syscalls, which you can probably guess is the part needed to allocate virtual memory from the OS.

But as long as your allocator has enough spare virtual memory, it shouldn't need to do a syscall. And if you /really/ needed the ability GPU side, technically with signals you can actually just ask the CPU to allocate the virtual memory on the GPU's behalf and have the GPU spin until the allocation is "complete". Or with compiler support: automatically make the workgroup/kernel async and resume execution by enqueuing another kernel, but that sort of thing is kinda hard :).

Btw, the Rust framework is here: https://github.com/geobacter-rs/geobacter. I mostly work on it in my spare time, a scarce resource these days, so I admit it has some scuff.

> In such a case, I'd want the compute-graph to loop: while (kernel_X fails due to out-of-memory){ garbage_collect(); try kernel_X() again}.

Pretty much. Even garbage collection can (theoretically lol) happen on the GPU.

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#36

Post by dragontamer »

diamondlovesyou wrote: post #35
dragontamer wrote: post #34

Earlier quoted context omitted.

> you can enqueue most computation graphs Can those command graphs loop? I know this interface is undocumented... but I've had an idea for a GPU-language akin to Java or Lisp memory-management. The gist is that kernel_X() can execute, but may fail in any new() or malloc() command. In such a case, I'd want the compute-graph to loop: while (kernel_X fails due to out-of-memory){ garbage_collect(); try kernel_X() again}.…

> Can those command graphs loop? Not directly (barrier packets wait for 0 only, plus the queue packets aren't preserved), but kernels can write to any dispatch queue themselves, so you can get the same effect at the end of your "loop body". > I know this interface is undocumented... but I've had an idea for a GPU-language akin to Java or Lisp memory-management. The gist is that kernel_X() can execute, but may fail in…

> Pretty much. Even garbage collection can (theoretically lol) happen on the GPU.

Oh, that's the plan. Semispace collection is very clearly a problem that can be solved in parallel: https://en.wikipedia.org/wiki/Cheney%27s_algorithm

That's just a breadth-first traversal over the fromspace. That's like... GPU programming 101 level material there. Its obviously parallel.

That's why Java/Lisp is the model I'm using, because they use semispace malloc / semispace garbage collection. 100% GPU-side malloc / garbage collection.

Nothing that I'm working on for real, mostly just theory-craft. But fun to think about on my spare time. I would expect that semispace garbage collection and allocation of memory would be very efficient on GPUs, and serve as the basis of some higher-level abstraction.

-------

The "while loop" would need a custom compiler to emit the trampoline / continuation, so that the kernel knows how to "restart" itself in cases where the malloc() fails and garbage collection was run.

Kernels exiting serves as the innate synchronization point, the "synchronized stop" in the stop-the-world garbage collection schemes.

If I could write a routine that saves off every "malloc" as a possible "continuation" point (possibly saving that information in a queue-data structure or stack-data structure of some kind), then it probably would work.

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#37

Post by N1H1L »

baybal2 wrote: post #11
diamondlovesyou wrote: post #7

Earlier quoted context omitted.

Machine learning isn't the only useful thing to run on "GPU"s (these can't do graphics workloads anymore; they're basically just vector processors). AMD isn't attempting to complete on f16 perf. They're completing where Nvidia's perf is abysmal: f64. Having programmed AMDGPUs at a lower level than HIP/Rocm, they are actually much better than Nvidia (and in fact I'm able to do cool things like pcie large bar/p2p even…

That's a smart move given GPUs may now loose a lot of market as "AI" thing is rapidly losing steam, and SLIDE is getting better, and better.

They also have a company called ThirdAI to commercialize SLIDE

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#38

Post by volta83 »

my123 wrote: post #18
volta83 wrote: post #12

I wonder how they manage to keep the FP64 units busy. Seems this is an HPC product, but many HPC apps are memory bound. So to improve FP64 perf by 4 one might need to improve DRAM bandwidth by 8-16x. Otherwise the units would only be stalled waiting for memory. But it seems they did not improve bandwidth by much?

> I wonder how they manage to keep the FP64 units busy They don’t. See https://www.amd.com/en/graphics/server-accelerators-benchmar... . The MI250X, despite being dual big dies, doesn’t do especially well.

Makes sense. Comparing nodes with 2x or 4x MI250X vs 4x or 8x A100-80 it doesn't really seem that there is any speed up at all for memory bound apps.

Re: Stacking Up AMD MI200 versus Nvidia A100 Compute Engines

#39

Post by volta83 »

dragontamer wrote: post #31
volta83 wrote: post #12

I wonder how they manage to keep the FP64 units busy. Seems this is an HPC product, but many HPC apps are memory bound. So to improve FP64 perf by 4 one might need to improve DRAM bandwidth by 8-16x. Otherwise the units would only be stalled waiting for memory. But it seems they did not improve bandwidth by much?

> Seems this is an HPC product, but many HPC apps are memory bound. The point of a supercomputer is to throw so much compute at a problem, that everything else is the bottleneck. If an HPC app is memory-bound, then the GPU / Supercomputer was successful at its job. So many HPC apps are memory bound because... well... turns out our machines are actually quite good. In any case, MI200 has 1.6x the bandwidth as the A100…

I agree with you, which is why I don't really understand what the point of improving FP64 perf by 4x is, if that is not the bottleneck for many apps.

Per node, a 4x MI250X node has more or less the same BW as a DGX-A100 (8x A100). It has 2x more FP64 compute, but for most science and engineering apps, which are memory bound, 2x more FP64 compute does not make these apps any faster.

Post reply on HN