Live data from Hacker News

AMD may get across the CUDA moat

hpcwire.com

291–300 of 312 posts

Re: AMD may get across the CUDA moat

#291

Earlier quoted context omitted.

Re: startups, Geohotz raised a few million for this already. https://tinygrad.org/

Didn't he do what he always does. Rake in a ton of money, fart around and then cash out exclaiming it's everyone else's fault? The way he stole Fail0verflow's work with the PS3 security leak after failing to find a hypervisor exploit for months absolutely soured any respect I had for him at the time

Are you interested in being factually correct, or are you interested in hating? If it's the former, I think you should do some research. If it's the latter, :salute:

I had GPT-4 do some research for you, hopefully you will incorporate it in future comments you make about me. https://chat.openai.com/share/d0fa24e9-3ed7-4b17-8497-24bfdd...

Re: AMD may get across the CUDA moat

#292

Is there any reason OpenCL is not the standard in implementations like PyTorch? Similar performance, open standard, runs everywhere - what's the downside?

Downsides are it can't express a bunch of stuff cuda or openmp can plus the nvidia opencl implementation is worse than their cuda one. So opencl is great if you want a lower performance way of writing a subset of the programs you want to write.

Re: AMD may get across the CUDA moat

#294

> AMD May Get Across the CUDA Moat I really wish they would, and properly, as in: fully open solution to match CUDA. CUDA is a cancer on the industry.

What's wrong with CUDA? I avoided it for years because it's proprietory but about one year ago I started using it because all the alternatives (OpenGL/Vulkan compute, OpenCL, WebGPU, ...) couldn't quite do what I wanted, and it turned out to be a game changer. Nothing comes close to it. Now I'm hooked because there simply isn't an alternative that's as easy to use, yet powerfull and fast. I wish there was an open alt…

> What's wrong with CUDA?

Read on

> it's proprietory

Yes indeed, proprietary

> Now I'm hooked

There you go.

> I wish there was an open alternative

So does the rest of the industry.

Specifically, it forces you to run your stuff on NVidia hardware and gives you exactly zero guarantee of future support.

Good luck trying to reproduce whatever research you are currently conducting in 10 years time.

Vendor lock-in + no forward compatibility guarantee = surefire recipe for getting milked to the bone by NVidia.

Re: AMD may get across the CUDA moat

#295
post #273

Earlier quoted context omitted.

IIRC, ease of implementation (for the GPU kernels), and cross-compatibility (the same bytecode can be loaded by multiple models of GPU).

How is CUDA-C that much easier than OpenCL? Having ported back and forth myself, the base C-like languages are virtually identical. Just sub "__syncthreads();" for "barrier(CL_MEM_FENCE)" and so on. To me the main problem is that Nvidia hobbles OpenCL on their GPUs by not updating their CL compiler to OpenCL 2.0, so some special features are missing, such as many atomics.

Never used it myself, these are just the main reasons I've heard from friends.

Re: AMD may get across the CUDA moat

#296

Earlier quoted context omitted.

I'd say with semver becoming far better known, this is not a problem for "any" software development. The developer gets the choice to pick libraries that are stable, often also influencing language choice. Mistakes happen, Guava broke the Java ecosystem for about two years, but it's never something that is accepted as just a fact of software development, it is a mistake. Wanting to hold Python+C ecosystem more accoun…

Semver is a joke and doesn't work. Languages like C and C++ can easily have problems if you link code built with different versions together (even if you aim for them to be compatible, or even if they are indeed the same source version but with subtly different flags), and there are no good solutions for this, except not doing it. A docker container is not really any different from any other process; the main differe…

> problems if you link code built with different versions

But that has nothing to do with semver.

Semver gives you information about when when you can replace one version with another version. It doesn't promise that you can mix multiple versions together.

Re: AMD may get across the CUDA moat

#297
post #26

CUDA is the only reason I have an Nvidia card, but if more projects start migrating to a more agnostic environment, I'll be really grateful. Running Nvidia in Linux isn't as much fun. Fedora and Debian can be incredibly reliable systems, but when you add an Nvidia card, I feel like I am back in Windows Vista with kernel crashes from time to time.

My Arch system would occasionally boot to a black screen. When this happened, no amount of tinkering could get it back. I had to reinstall the whole OS. Turns out it was a conflict between nvidia drivers and my (10 year old) Intel integrated GPU. But once I switched to an AMD card, everything works flawlessly. Ubuntu based systems barely worked at all. Incredibly unstable and would occasionally corrupt the output and…

I'm not sure what card you have but I've never really had any major problems running Nvidia + Intel integrated graphics on Arch, Ubuntu etc.

Re: AMD may get across the CUDA moat

#298

Earlier quoted context omitted.

What's wrong with CUDA? I avoided it for years because it's proprietory but about one year ago I started using it because all the alternatives (OpenGL/Vulkan compute, OpenCL, WebGPU, ...) couldn't quite do what I wanted, and it turned out to be a game changer. Nothing comes close to it. Now I'm hooked because there simply isn't an alternative that's as easy to use, yet powerfull and fast. I wish there was an open alt…

> What's wrong with CUDA? Read on > it's proprietory Yes indeed, proprietary > Now I'm hooked There you go. > I wish there was an open alternative So does the rest of the industry. Specifically, it forces you to run your stuff on NVidia hardware and gives you exactly zero guarantee of future support. Good luck trying to reproduce whatever research you are currently conducting in 10 years time. Vendor lock-in + no for…

Those are some poor arguments, imho, because there literally is no other option than CUDA. The alternatives are so bad, it's far better to be vendor-locked and being able to get stuff done, than not being able to get stuff done at all.

As I said, I avoided it for years because of the reasons you mentioned. Turns out I could not avoid it any longer because it's the only (meaningful) option that could do what I needed, has serious support, and great UX. And NVIDIA is hardly to blame because they simply made sure to build a good product. It can't stop AMD, Intel or Khronos from creating a competitive alternative, but so far they haven't.

And regarding support, so far NVIDIA has shown excellent continuous support for CUDA, whereas OpenCL and OpenGL are the ones that went down. And I've chosen CUDA over rocm precisely due to support reasons, because AMD has always treated it as some kind of side gig with uncertain future.

Re: AMD may get across the CUDA moat

#299

Earlier quoted context omitted.

Blame Nvidia. They are the ones the got the industry hooked on a proprietry API.

Why would I blame NVIDIA? If it wasn't for them, we'd still only have needlessly cumbersome APIs and ecosystems. They did what Khronos always failed to do: They created something that is both easy, powerful and fast. Khronos always heavily neglects the easy part.

Blame them for being anti competitive and anti consumer.

Re: AMD may get across the CUDA moat

#300
post #274

Earlier quoted context omitted.

My guess is when FB does run into such flakiness they email ____.____@nvidia.com as part of some support contract they have and go "Yo, we see this issue, figure it out and fix it". But I can promise you after reading things like the LKML for decades and a number of different Microsoft blogs, that everyone on this planet experiences flakiness issues at times and has to figure out how to adjust their workload to avoid…

He has described to me, in detail, some of the challenges they have had. I'm not saying it's exhaustive but I'm pretty sure if their experience with the fundamental software stack was what people here are claiming I would never hear the end of it. Actually, no. Obviously they have Nvidia support but in one especially obscure issue he was describing Meta took it as an internal challenge and put three teams on it in co…

On the flip side, one of the reasons I'm loyal to nvidia is a combination of two things.

1. They supported linux when no one else did, 2. I've never experienced instability from their drivers, and as I mentioned before, I've been running their cards under linux since the TNT2 days.

Post reply on HN