Live data from Hacker News

HipKittens: Fast and furious AMD kernels

hazyresearch.stanford.edu

31–40 of 94 posts

Re: HipKittens: Fast and furious AMD kernels

#31
post #12
post #9

Earlier quoted context omitted.

From the performance comparison table, basically AMD could be NVIDIA right now, but they aren’t because… software? That’s a complete institutional and leadership failure. Ironically, building chips is the actual _hard_ part. The software and the compilers are not trivial but the iteration speed is almost infinite by comparison. It goes to show that some companies just don’t “get” software. Not even AMD!

I'd go so far as to say it's the exact opposite. It's faster and easier to change the hardware than the software.

Counterproof: attempt to modify your graphics card. Then attempt to modify a piece of code. Which one was easier?

Re: HipKittens: Fast and furious AMD kernels

#32

Full disclosure, we have a contract with AMD to get Llama 405B training on MI350X on MLPerf. Things are turning around for AMD. If you have an AMD card, go to pytorch.org, click Linux+ROCm and install PyTorch. 3 years ago, this was hopeless. Today, most mainline things work. I ran nanochat on MI300X and it just worked. I think that's true about MI350X now too. The MI350X machine is stable. They are clearly behind NVI…

As CEO of an AMD NeoCloud for the past 2 years, it is so nice to hear all this and also see the turn around. It is what I bet my business on from the start and I can concur with what George is saying 100%.

The out of box experience can be a bit rough around the edges on bleeding edge stuff, but it isn't anything near as bad as it used to be. For example, a month ago nanochat wasn't working well and now it is. The important thing is that people now care enough to make it work.

At the end of the day, AI does need viable options. Having a monopoly on all AI hardware and software might be a good thing for share holders, but isn't a good thing for what is looking like a fundamental technology, akin to the internet.

Re: HipKittens: Fast and furious AMD kernels

#33
post #17

Earlier quoted context omitted.

The MBAs are in charge, and now AMD is the new Intel? It's not only not fixable overnight, but it's not fixable at all if the leadership thinks they can coast on simply being not as bad as Intel, and Intel has a helluva lot of inertia and ability to simply sell OEM units on autopilot. Sounds like the AMD board needs to get their heads out of their asses and shake up leadership.

The MBAs have always been in charge to an extent. But the real issue is we don't want to invest in beating Nvidia on quality. Otherwise we wouldn't be doing stock buybacks and instead use the money on poaching engineers. The mindset is that we maintain a comfortable second place by creating a shittier but cheaper product. That is how AMD has operated since 1959 as a second source to Fairchild Semiconductor and Intel.…

Get rid of half the lawyers who are sitting in the way most of the time and take the risks necessary to move closer to the top.

Re: HipKittens: Fast and furious AMD kernels

#34
post #3

Earlier quoted context omitted.

Infiniband is being replaced with UEC (and it isn't needed for inference). For inference there is no moat and smart players are buying/renting AMD or Google TPUs.

I didn't know you can you buy Google TPUs now?

You can buy older less capable TPUs https://www.seeedstudio.com/Coral-USB-Accelerator-p-2899.htm...

Re: HipKittens: Fast and furious AMD kernels

#35
post #23
post #19

Earlier quoted context omitted.

> AMD never misses an opportunity to miss an opportunity Well said, their Instinct parts are actually, at a hardware level, very very capable pieces of kit that - ignoring software/dev ecosystem - are very competitive with NVidia. Problem is, AMD has a terrible history of supporting it's hardware (either just outright lack of support, cough Radeon VII; or constantly scrapping things and starting over and thus the eco…

Our hardware is arguably better (spec for spec) apart from critical areas like memory bandwidth, and GPU to GPU bandwidth. You can tweak your implementations to get the same if not better performance. We do that, we see this, our customers see this. ROCM pre Rock, suffers from the ossification in the engineering organization. The Rock seeks to completely change that, and the team driving it is amazing. Try out the pr…

> There is hope.

Indeed. For clarity, I agree the performance is certainly there. My comment about being behind was in the context of marketshare and ecosystem maturity compared to CUDA. In fact, I'd say there's more than just hope but actual meaningful progress and commitment being made there, and I'm happy to see it.

Re: HipKittens: Fast and furious AMD kernels

#36
post #2

One thing I don't understand about Nvidia’s valuation is that right now a small number of algorithms have 'won,' such as Transformers. The data is very important. Compared to the past where customized code was much more common, such as modeling code and HPC, the ecosystem was very important and it was almost impossible to implement all CUDA and related code. Competitors now only need to optimize for a narrow set of a…

Transformers aren’t really one thing, the way they are implemented is wildly different. If it wasn’t then vllm and TRL would be easy

[deleted]

Re: HipKittens: Fast and furious AMD kernels

#37
post #14

You'd think AMD would swing in on something like this and fund it with the money needed to succeed. I have no knowledge of it but my guess is no, AMD never misses an opportunity to miss an opportunity - when it comes to GPUs and AI.

AMD pays the bare minimum in software to get a product out the door. The company does not even have working performance testing and regressions routinely get shipped to customers. Benchmarks the executives see are ad hoc and not meaningful. HipKittens is an improvement but AMD does not have the ability to understand or track kernel performance so it'll be ignored. This isn't fixable overnight. Company-wide DevOps and…

This doesn't sound right. I definitely got yelled at over trivial performance regressions which looked like noise so people were measuring performance.

They've paid serious amounts in RSUs over the last six years. Not top of market by any stretch but firmly in the category of engineers don't care what the steak costs. Bonus might be team dependent, I remember being annoyed and nicely surprised by it in different years.

The aql profiler confuses me quite a lot but it's definitely a tool for measuring performance.

Re: HipKittens: Fast and furious AMD kernels

#38

Earlier quoted context omitted.

I didn't know you can you buy Google TPUs now?

You can buy older less capable TPUs https://www.seeedstudio.com/Coral-USB-Accelerator-p-2899.htm...

these are not remotely like anything Google uses in the datacenter, even a decade ago.

Re: HipKittens: Fast and furious AMD kernels

#39
post #7

Earlier quoted context omitted.

The vast amount of CUDA libraries for anything you can think of. I think there’s where they have the biggest leverage.

AI is going to be so ubiquitous, something principled and open is going to supersede cuda at some point, as HTML5 did for Flash. CUDA isn't like an x86 vs ARM situation where they can use hardware dominance for decades, it's a higher level language, and being compatible with a wide range of systems benefits NVIDIA and their competitors. They're riding out their relative superiority for now, but we're going to see a s…

> as HTML5 did for Flash

Uh, Flash died because Apple refused to support it on mobile Safari. Perhaps Flash would have died anyway, but that is the proximate cause. And Apple's competitors were falling over themselves to market Flash support as a competitive advantage vs. iPhone.

Re: HipKittens: Fast and furious AMD kernels

#40

Full disclosure, we have a contract with AMD to get Llama 405B training on MI350X on MLPerf. Things are turning around for AMD. If you have an AMD card, go to pytorch.org, click Linux+ROCm and install PyTorch. 3 years ago, this was hopeless. Today, most mainline things work. I ran nanochat on MI300X and it just worked. I think that's true about MI350X now too. The MI350X machine is stable. They are clearly behind NVI…

Does consumer hardware (non-MI) need proprietary kernel drivers for running rocm + pytorch?
Post reply on HN