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]
CUDA Moat Still Alive
151–160 of 176 posts
Re: CUDA Moat Still Alive
#152Earlier 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…
Re: CUDA Moat Still Alive
#153Earlier 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.
https://www.infinibandta.org/infiniband-and-roce-advances-fu...
Where are you getting your information?
Re: CUDA Moat Still Alive
#154Earlier 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…
Did make me wish I bought a Nvidia.
Re: CUDA Moat Still Alive
#155"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"
Re: CUDA Moat Still Alive
#156Earlier 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.
Re: CUDA Moat Still Alive
#157Earlier 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.
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
#158Earlier 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.
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
#159Earlier 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?
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
#160Earlier 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.