Live data from Hacker News

CUDA Moat Still Alive

semianalysis.com

151–160 of 176 posts

Re: CUDA Moat Still Alive

#151
post #84

Earlier quoted context omitted.

Engineers at hyperscalers are struggling through all the bugs too. It's coming at notable opportunity cost for them, at a time when they also want an end to the monopoly. Do they buy AMD and wade through bug after bug, regression after regression, or do they shell out slightly more money for Nvidia GPUs and have it "just work". AMD has to get on top of their software quality issues if they're ever going to succeed in…

> Engineers at hyperscalers are struggling through all the bugs too [citation needed]

It's in the article. Meta don't use AMD for training and write their own kernels for inference. You can't train with AMD, full stop, because their software stack is so buggy.

Re: CUDA Moat Still Alive

#152
post #129

Earlier quoted context omitted.

Others can build infiniband hardware according to the standard. There used to be at least two companies building infiniband hardware until Intel killed QLogic’s infiniband division in a misguided attempt to make its own monopoly. :/

Or they can develop a RoCEv2 that works (which is basically what UltraEthernet is). Infiniband is not fun - it's a special snowflake of an interconnect that sits parallel to the rest of your datacenter network, and can not really run a standard TCP/IP codebase (yeah IPoIB is a thing but still). Do the Nvidia boxes really need a scale-out IP network as well as an Infiniband network? Plus the spec is old. Packet sprayi…

We must agree to disagree then. Infiniband is an awesome technology. It was originally meant to to serve as a fabric to connect all components in a computer. That plan died with the dotcom bubble as it was too ambitious and therefore risky, so it was relegated to networking where it was an incredibly good job in delivering messages reliably and fast. It still am hopeful someone will do that someone will do it.

Re: CUDA Moat Still Alive

#153
post #135

Earlier quoted context omitted.

Nvidia is the one who went to an industry standard before their competitors in this space. It was created in 1999 and is called infiniband: https://en.wikipedia.org/wiki/InfiniBand Infiniband is extremely popular in the HPC space, which is why Nvidia adopted it. Everyone else saw Nvidia adopt it and said "Let us make a new network standard to be incompatible". This is mind boggling. Even more mind boggling is that ma…

Sorry to hound you for the third time, but this is wrong: > Infiniband is extremely popular in the HPC space Not anymore. There used to be Cray Aries/GNI, psm/psm2, and now there's Slingshot, the new Cornelis stuff etc. There's almost no Infiniband now.

The top500 says otherwise:

https://www.infinibandta.org/infiniband-and-roce-advances-fu...

Where are you getting your information?

Re: CUDA Moat Still Alive

#154
post #7

Earlier quoted context omitted.

AMD's software for consumer GPUs demonstrates a lack of seriousness. ROCm only officially supports RDNA2 and RDNA3 GPUs (their last two generations of hardware), and for some reason most of them are supported on only Windows ( https://rocm.docs.amd.com/projects/install-on-windows/en/lat... ) and not Linux ( https://rocm.docs.amd.com/projects/install-on-linux/en/lates... ), where most AI training and inference occurs.…

In practice, consumer Navi 21 based cards (RX 6900XT etc) and Navi 31 cards (RX 7900 XTX etc) are compatible with Pytorch on Linux. What they write about ROCm and Windows is equivocation. They target only one app: Blender. Pytorch+ROCm+Windows does not work. I had bought a 6900XT myself around launch time (the RTX3080 I ordered was not coming, it was the chip shortage times...) and it took around 2 years for Pytorch…

Maybe, but it's pretty lame when you buy a new $500 CPU (7800 XT) and the docs say it's unsupported, and makes you feel like even if you reported a bug they would just say "Sorry, not supported".

Did make me wish I bought a Nvidia.

Re: CUDA Moat Still Alive

#155
Latest: Dylan Patel ( SemiAnalysis )

"Met with @LisaSu today for 1.5 hours as we went through everything

She acknowledged the gaps in AMD software stack

She took our specific recommendations seriously

She asked her team and us a lot of questions

Many changes are in flight already!

Excited to see improvements coming"

https://x.com/dylan522p/status/1871287937268383867

Re: CUDA Moat Still Alive

#156

Earlier quoted context omitted.

This is baffling. I’m sure there are many technical reasons I don’t grok that AMD’s job is challenging, but it’s wild that they are dropping the ball on such obvious stuff as this. The prize is trillions of dollars, and they can print hundreds of millions if they can convince the market that they are closing the gap. It’s embarrassing that whoever actually tries to use their product hits these crass bugs (same with g…

There's a recent interview with Lisa Su where she basically says she's never been interested in software because hardware is harder, she doesn't believe AMD has any problems in the software department anyway and AMD is doing great in AI. So make of that what you will. Suffice it to say, clearly the AMD board doesn't care either because otherwise they'd replace her.

--> https://x.com/dylan522p/status/1871287937268383867

Re: CUDA Moat Still Alive

#157

Earlier quoted context omitted.

> Engineers at hyperscalers are struggling through all the bugs too [citation needed]

It's in the article. Meta don't use AMD for training and write their own kernels for inference. You can't train with AMD, full stop, because their software stack is so buggy.

> It's in the article

The same article also states that AMD provided custom bug-fixes written by Principle Engineers to address bugs in a benchmark - this is software that will only become part of the public release in 2 quarters. I ask again, do you think AMD will not expedite non-public bug-fixes for hyperscalers?

> You can't train with AMD, full stop, because their software stack is so buggy.

Point 7 from the article:

>> The MI300X has a lower total cost of ownership (TCO) compared to the H100/H200, but training performance per TCO is worse on the MI300X on public stable releases of AMD software. This changes if one uses custom development builds of AMD software.

I have an inkling that Meta does not obtain MI300 drivers from https://download.amd.com

Re: CUDA Moat Still Alive

#158
post #90
post #76

Earlier quoted context omitted.

> For matmul I'm not sure what your overhead is beyond moving memory, multiplying, and adding. A platform touting a memory bandwidth and raw compute advantage should have that covered. Where is the performance being lost? The use of the word 'algorithm' is incorrect. Look... I do this sort of work for a living. There has been no useful significant change to matmul algorithms . What has changed is the matmul process .…

To be fair, GEMV is memory bandwidth bound and that is what token generation in transformers uses. GEMM is the compute bound one, provided you do not shoehorn GEMV into it. That special case is memory bandwidth bound.

GEMM isn't compute bound in ML in practice. If you do naive GEMM based attention, then you will have to write the output matrix into HBM and in the worst case you might even have to reload the output from HBM!

So what is done in practice is an algorithm that doesn't calculate the same result, but is imperceptibly close to doing classic attention, namely flash attention. Flash attention lets you fuse the kernel so that you can multiply against the V matrix and therefore write the condensed output to HBM. As an additional benefit you also go from quadratic memory usage to linear memory usage. But here is the problem: Your SRAM is limited and even flash attention is still O(n^2) in compute. This means if you tile your K and V cache into j and k tiles. You will have to load j*k times from memory. Meanwhile compute tends to consume very little silicon area. So you end up in a situation where you have excessive compute vs your SRAM. In the compute > SRAM regime, doubling SRAM size also doubles performance. You're memory bound again for super long contexts.

Now let's assume the opposite. Your compute resources are improperly sized with regards to your SRAM, you have too much SRAM but not enough compute resources e.g. a CPU. You will be compute bound with regard to a linear factor vs your SRAM, but always memory bound vs main memory. You could add the matrix cores to the CPU and the problem would disappear in thin air.

Re: CUDA Moat Still Alive

#159

Earlier quoted context omitted.

> Hyperscalers are also more self-sufficient at software: they have entire teams working on PyTorch, Jax, and writing kernels. None of this matters because AMD drivers are broken. No one is asking AMD to write a PyTorch backend. The idea that AMD will have twice the silicon performance than nvidia to make up the performance loss for bad software is a pipedream.

> None of this matters because AMD drivers are broken Do you honestly think the MI300 has show-stopper driver bugs, or that Meta/Amazon doesn't have a direct line to AMD engineers?

>Do you honestly think the MI300 has show-stopper driver bugs

Yes

>Meta/Amazon doesn't have a direct line to AMD engineers?

I don't even think AMD engineers have a direct line to AMD.

Re: CUDA Moat Still Alive

#160

Earlier quoted context omitted.

> None of this matters because AMD drivers are broken Do you honestly think the MI300 has show-stopper driver bugs, or that Meta/Amazon doesn't have a direct line to AMD engineers?

> Do you honestly think the MI300 has show-stopper driver bugs Yes > Meta/Amazon doesn't have a direct line to AMD engineers? I don't even think AMD engineers have a direct line to AMD.

The fine article says they had the ears of VPs and Principal Engineers, just to help with a benchmark. Meta/Amazon will get white-glove service
Post reply on HN