YuechenLi
2 days ago
Nvidia's biggest advantage in AI has never been only their hardware performance but how entrenched their software is in ML research that flowed down stream. However, if you've actually used CUDA C/C++, it's pretty one of the worst software development ecosystem imaginable: you get all the footgun of regular C++, plus GPU compute pretending to be C++ and but doesn't actually behave like C++ because CPU and GPU compute are fundamentally different, and the only reason people put up with it is because Vulkan and HIP C/C++ are even worse.
Google's limitation is that they still don't offer TPUs in a PCI-E card/dev board that people can plug in to their PC for local development and sane low level API to develop against, instead you have to go through their cloud and their full software stack which greatly limits ecosystem growth. The minute that Google figures that out, that's when Nvidia's dominance would be challenged.
bri3d
2 days ago
The CUDA runtime coming with a gazillion reasonably decent kernels (DNN, BLAS, CUTLASS) and a concurrency system (NCCL) is a big deal; especially in the “early days” very few researchers or development runtimes were even writing their own kernels or dealing with CUDA C++ extensively, they were wrapping the ones NVidia gave them.
I do agree that it’s really not great, and I also have never been a strong believer in the CUDA moat overall; as the need for GPUs moves from research to production (inference), companies are plenty willing to build software from scratch anyway (and we see this with AMD GPUs being in plenty high demand in the datacenter and enthusiast market now).
galaxyLogic
2 days ago
What I don't quite get is why can't they use AI to translate CUDA programs into more open architectures like AMD ROCm?
AI is supposed have solved the "coding problem". But shouldn't translating a program from one platform to another be an even easier, more mechanical, task for the AI?
bri3d
a day ago
No, because the two platforms often don't share the same underlying kernels; this has been one of the main issues and complaints with ROCm/MIOpen since the start, although they are catching up slowly.
This is actually a corollary to the point I was making about "CUDA" usually also including a ton of the included kernels and not just referring to a crappy programming environment; translating mid-level C that does math between two runtimes wouldn't be hard for an LLM, but translating "doBigDNNThingNVidiaGaveMeInAKernel()" to "doBigDNNThingByHandBecauseAMDDoesntSupportIt()" isn't a rote translation at all.
Of course, once you accept that it's _not_ "why don't you just translate it," you _can_ iteratively use an LLM to implement the ThingNVidiaGaveYouInAKernel, but it probably isn't well-trained, yet, on low-level AMD optimization tricks, so the kernel you end up with will likely be slower than the CUDA one.
galaxyLogic
a day ago
> translating "doBigDNNThingNVidiaGaveMeInAKernel()" to "doBigDNNThingByHandBecauseAMDDoesntSupportIt()" isn't a rote translation at all.
I wonder if this points to a deeper limitation of AI, it can not do coding tasks it has not seen in its training material. Or could it possibly "generalize" to accompllish something like this anyway?
mdp2021
2 days ago
> AI is supposed have solved the
Which AI? LLMs are coding facilitators and code producers.
A problem is solved when the solution is reliable. Non-deterministic Neural Networks are not reliable. In fact,
> more mechanical[] task
that suggests an expectation of process and procedure, which is still not a capability of current architectures.
Sure, you can ask a brains-deficient operator to perform a huge task, but then you'll have to check the whole product, and that remains not cheap.
larnon
2 days ago
The tool itself (AI) may not be reliable, but that is also very true for every other tool (e.g. Human). Also, you are right about when a problem is solved, but this doesn't need the tool to be reliable as you said, just the solution part. Hence, as long as the produced code works as intended, it doesn't matter what you used to produce the output.
mdp2021
16 hours ago
> but this doesn't need the tool to be reliable as you said, just the solution part
And where are the warranties that the solution built be reliable (and optimal, etc.)?.
galaxyLogic
a day ago
Saw this on the web:
"AMD and Anthropic also formed a multiyear engineering partnership to optimize ROCm using Claude"
FROM: https://finance.yahoo.com/markets/stocks/articles/ex-amd-exe...
bugglebeetle
2 days ago
Undoubtedly, the frontier labs are already doing something akin to this as part of their new chip design endeavors.
ravenstine
2 days ago
That's really interesting. I have no experience writing anything that involves GPUs/TPUs, but over the years I've consistently read that CUDA is the "real moat" of Nvidia, which I never totally believed, but the way you describe makes it seem like it's not actually a moat in the slightest. It just happens to be an ecosystem associated with hardware that is not only considered the gold standard but happens to be more open than potential competition. Could it be that Nvidia has been on top because none of the competition has actually tried kicking them where it hurts?
kevstev
2 days ago
I think OP is overstating it a bit tbh. So Nvidia has the market for the hardware, which helps, but there is literally no alternative to CUDA. Nvidia keeps it a scalpel for skilled users, its not super easy to use, but unlocks orders of more magnitudes of power for the use cases it excels at vs CPUs. I don't have access to anything like it in the Apple ecosystem.
AMD has had years to try and counter it, but just has not. Google is kinda trying to do an end run around it with TPUs but they are still niche high end stuff with limited availability.
Its really just CUDA, and CUDA can be seen as somewhat akin to C for assembly used by Nvidia's gpus- In many ways a wrapper around the low level hardware that often has those details bleed through.
YuechenLi
2 days ago
I think there is a misconception here: CUDA is not even close to being C for assembly used by Nvidia's GPUs, PTX is, and it uses JIT to compile to Nvidia's GPU assembly, SASS. It honestly easier just to have LLMs write PTX directly than to go through CUDA C/C++ at all.
Again, "CUDA" isn't a programming language, it stands for Compute Unified Device Architecture; "C/C++ for CUDA" are the high-level languages that compiles to PTX and then SASS as well CPU orchestration code via NVCC.
And to be honest, pretty much everything you can do in CUDA C/C++, you can also do in HLSL/GLSL compiled to SPIR-V, as long as the Vulkan hardware extension is available.
kevstev
2 days ago
My point with the c comparison is that it often feels like a very thin layer that still requires you to know a lot about what's going on under the hood. It was more to give a view in what it's like to work with the lib/api.
Maybe I wasn't being precise enough with my language for this forum, and also my last hands on experience with it was roughly 6 years ago, maybe it's gotten better. But it was much less (and forgive the imprecision!) python/pytorch-like where you say hey take this big blob of data and just slice and dice it on your many cores, and more like ok, here is the data, let's cudamemcopy it in these size chunks over to the gpu itself, to be used by this block of threads and run these commands (kernel in cudaspeak) on it. Much more painstaking and micromanagey of the resources.
Pytorch IMHO feels like a proper abstracted API that hides the details and lets you just unleash the fury at the cost of some efficiency, while the cuda api itself, similar to working with C, forces you to really think about the low level details. I have a heavy backend and systems development background, and while it wasn't really intimidating to me, it was like wow you really have to have a deep working knowledge of how these things work and it felt like a step back in time IMHO.
I doubt that's going to satisfy you but I think it gives a clearer picture of what using cuda is like if you typically use higher level languages and haven't touched C since college.
YuechenLi
2 days ago
I think you are pretty precise and your comment is appreciated, so I think I need to clarify my wording as well. I think a lot of CUDA C/C++'s difficulties are self-inflicted because they conflate two things into what they call "kernels": runtime and shaders. Fundamentally, GPU programming for compute is easier than either graphics programming as well as CPU programming because you are limited on what you can do on the GPU, memory allocation is static because the matrix size doesn't really change dynamically during runtime and branching behaviors are generally to be avoided for GPU compute.
It's pretty heretical for me to say this, but a lot of GPU compute complexity that Nvidia is doing in CUDA is unnecessary and is by the simple fact that to do anything meaningful you have to either use their library or handle allocation/scheduling yourself. Imagine if JavaScript required you to handroll part of the V8/Node's JIT compiler, allocator and scheduler yourself every time you just want to make a webpage, that is essentially what CUDA is doing.
The actual "program" that runs on the GPU, the compute shaders in PTX/SPIR-V, are very low level but pretty straight forward once you get down to it.
compiler-guy
2 days ago
To paraphrase the apocryphal Winston Churchill quote about democracy:
“CUDA is the worst development ecosystem in existence. Except for all the others.”
lostlogin
2 days ago
‘Yes, I Am Drunk, But CUDA is Ugly. Tomorrow I Will Be Sober, And CUDA Will Still Be Ugly.’
elictronic
2 days ago
Retraining a large high paid user base is often a non-starter. To put this in perspective, Boeing’s eventual retraining costs for all the pilots for the 737Max was around 5 billion dollars.
Looking at software more specifically the Linux foundation reported based on software dev salaries in 2008 it would be 1.4 billion to only write the Linux kernel.
Up until about 2023 there wasn’t enough money involved to have any reason to make a real CUDA killer even if you could get it adopted.
0xDEAFBEAD
2 days ago
As agentic coding continues to improve, won't it get easier for devs to retrain for new languages/frameworks/etc.?
galaxyLogic
2 days ago
And couldn't we just ask AI to translate our program in one language/framework into another?
I was under the impression that AI was supposed to remove software-moats, let us all ask it to write our custom MS Word for us for instance?
mandeepj
2 days ago
Yet, Microsoft pulled it off with a new .NET Framework, and Apple with its new iOS SDK. There are many more examples besides those two.
eterm
2 days ago
Microsoft pulled it off with dotnet, sort of, because they approached it like a completely new language, sold people on the benefits of it.
And the people they were selling that to, ( It's free and open souce now! ), were a very different group to the market they left behind on .NET Framework, who are often still struggling to make the transition now.
Had they actually killed off .NET Framework, it would have been a different story, much more like the VB6/VBA to VB.NET transition, which so few people bothered with that VB.NET died out, because if you had to retrain that much, you figured you might as well go to C# or a instead, or indeed a completely different language entirely.
I briefly worked professionally on a VB.NET project, but outside that job I've never met anyone else who can say the same. I've met a few who went straight from VB6 to C# though.
radicalbyte
2 days ago
The whole push behind .Net Core was to get .Net running on Linux well and natively and was being lead largely by those of us using .Net for web. We were being murdered by other languages at the time; mono was an option but Microsoft shops usually needed to target something blessed/backed by MS.
Largely the same market (Enterprise) but not the different segment (web as opposed to Windows/WinForms).
I ported about 15 years of projects from various versions of .Net to .Net Core whilst they were developing (and sent feedback to the team - they were asking us to do that) and the process was pretty reasonable. You were only really stuck if you were using something very very Windows specific (certain image processing libraries iirc) and even then it was largely manageable.
The old full-fat framework is, AFAIK, still supported, as there's a whole lot of legacy code which is Windows specific which is still expensive / hard to port over.
eterm
2 days ago
Unfortunately "something windows specific" was pretty broad.
Between MSMQ, WCF over named pipes, MSDTC, and MSI installers, there's a lot to replace that is hard to provide the same guarantees or performance with straight replacements, if they even exist.
The end goal, being on modern dotnet, is better, but it's difficult to get there with a phased approach without accepting a temporary worsening, which is often hard to sell.
Especially while Framework is still supported.
compiler-guy
2 days ago
Both of those were a vendor X electing to stop updating framework A in favor of framework B. That’s a high cost for vendor X’s users, but if their business depends on vendor X, they have no choice. Maybe they can switch to vendor Y at that point, but now you are switching both vendors and frameworks.
Replacing CUDA with another framework has much lower motivation. That advantages of the new framework must cover the switching costs and the risk of such a switch. All while CUDA continues to evolve and allow access to additional features.
Apple and Microsoft had something of a captive userbase. New vendor on the block trying to replace CUDA does not.
dragonwriter
2 days ago
Neither of those are a competitor replacing another, they are a same-vendor replacement. This is easier, because the company whose established product you are trying to displace is cooperating (because its you!) not actively resisting.
galaxyLogic
2 days ago
Anthropic rewrote Bun in Rust, with much help from AI of course
calebkaiser
2 days ago
It's a totally reasonable question, and one that everyone asks when they're learning about CUDA. The frustrating answer to your last question is that lots of companies have shipped GPU dev environments that can theoretically be used instead of CUDA. AMD has ROCm, Apple has had a couple projects (OpenCL, Metal), Intel has some stuff, and there are newer efforts like TinyGrad + a generation of slightly higher level frameworks from AI companies, like Triton from OpenAI.
The basic problem is that CUDA has become something of a Schelling point. If you want to train a model right now, the highest performance you can get is almost certainly on CUDA. From the basic general matrix multiply operation, to specific NN architectures, CUDA is going to have incredibly optimized implementations out of the box. And it's going to make multi-GPU training so much easier. And all the dependencies you build on (those layers you import from PyTorch or Transformers or whatever) are going to work optimally right away on CUDA. And that weird random repo that you found with a unique optimizer--it runs on CUDA too. And now the cool new implementation that you're about to release is also going to be built for CUDA.
It's so tempting to think "Just write replacement software", but you also need to transition the entire ecosystem in large part to match CUDA's effectiveness, and you need to get comparable performance out of your chip/library combo as NVIDIA can get out of its cards with CUDA.
There's a whole story here to how effective NVIDIA has been at navigating this. Very early on, they heavily prioritized PyTorch and TensorFlow, getting involved in the projects as much as they could and making sure they always ran best on CUDA. But the TLDR is that yes, you're right, another company could write a CUDA competitor. But actually replacing CUDA is a much larger task.
I'm personally hopeful that with the rise of coding agents, we see more movement on this front with other projects moving into view. It will take some time for any ecosystem to start to emerge that can dislodge CUDA for researchers who don't want to dive that deep into the stack, but hopefully we start to see some momentum build.
cepp
2 days ago
One of the rarely-mentioned value adds Nvidia provides is nccl[1] which makes multi-node networking and topology essentially plug and play. The other players have since caught on [2][3] and are working hard to catch up but I'd say networking is a real moat.
[1] https://developer.nvidia.com/nccl [2] https://pytorch.org/blog/torchcomms/ [3] https://rocm.docs.amd.com/projects/rccl/en/latest/
dannyw
2 days ago
CUDA has many problems, but I would say less problems than ROCm, etc; even before considering the ecosystem and that more people (or open source projects) have already solved CUDA's problems for you.
Ironically, there was an open source project that was making great progress on CUDA compatibility on AMD hardware. AMD hired the lead developer, and then he shut down the project.
bri3d
2 days ago
ZLUDA is still alive. AMD sponsored it and the project was briefly halted during a dispute with them, but it’s been making steady progress.
It doesn’t really make sense for AMD themselves or most use cases, though; any compatibility shim just adds problems on top of problems, and for AMD, entrenching a competitors technology even more never really seemed like a great idea.
csomar
2 days ago
Software has always been the moat but for some reason it's always hamstrung by upper management. The latest of the frenzies being replacing sane (or whatever we have) of development practices with AI-slop.
Management likes it because it removes software developers from the loop.
szundi
2 days ago
[dead]
musebox35
2 days ago
The biggest advantage of tpus is the high bandwidth fiber optic interconnect between them that allows distributed computing on pods with thousands of tpus and the co-design of cooling systems that go with their racks. I do not think that we will see personal tpus any time soon.
ijidak
2 days ago
Genuine question. Given that LLMs are supposed to allow us to rewrite anything, and I am an LLM believer, what I don't understand is: how does CUDA continue to be a moat in a world where LLMs can rewrite entire software development stacks? If NVIDIA is right about AI, isn't this same technology going to erode the software side of this same software moat?
polanyer
2 days ago
It seems like path dependent lock in to me and a risk/reward calculation.
What do you gain by not using CUDA vs what do you risk?
gr_norm
2 days ago
Indeed. Now, given that CUDA is apparently not being usurped, update your priors.
ceehex
2 days ago
well done you realised no one knows what they are talking about
whatever1
2 days ago
Now with LLMs why a programming framework is a moat?
tomaskafka
2 days ago
I had a hard time understanding why didn’t AMD make a better developer experience for this two years ago, and am now even more baffled that even with all the LLMs they still don’t seem to have moved a single inch, despite this probably being a tens of billions dollars worth feature.
kllrnohj
2 days ago
LLMs make the dev environment almost irrelevant. llama.cpp supports AMD with both ROCm and Vulkan and that's nearly all that matters now. TBD how much AMD's AI Halo play will change things if at all, but they got a lot of positive press in launch reviews for having an actually robust software story for once.
CorrectHorseBat
2 days ago
Hardware companies are notoriously bad at software. The software they use sucks, the languages they use suck, the internal tooling software they write sucks.
They don't know what good developer experience is, how do you expect them to deliver it to other people?
akoboldfrying
2 days ago
Interesting take on Google's TPUs. What I've previously heard (and still believe) is that Google's decision to only rent out, never sell, their TPUs is a deliberate and savvy strategy for bolstering GCP, which will work provided that TPUs are able to actually compete with other hardware (in practice meaning Nvidia). A few months ago there was some discussion on HN comparing them, and I think the verdict at the time was that their latest-gen TPUs win on compute-per-Joule for LLM-type workloads by quite a margin, which I think is huge for those who want to run LLMs at scale.
schopra909
2 days ago
I’m not entirely sure if local development will lead to Nvidia’s supremacy being challenged.
I think a simple reason why it’s been hard to unseat in Nvidia is first mover advantage. A lot more water has flown through Nvidia pipes than TPUs or AMDs chips for that matter.
TPUs and AMD chips aren’t priced cheaper than NVIDIA (at least for my purposes training models). So there hasn’t been an impetus for me to venture there and use those chips.
Anecdotally, folks I know who have tried using TPUs and AMD chips have hit more issues with the underlying drivers than with NVIDIA chips. That costs time and money to fix.
Eventually the other chips will go through enough iterations and stability will be reached
npunt
2 days ago
Are the switching costs of CUDA ecosystem potentially threatened because LLMs are now quite good at transcoding into other languages? In other words, is Nvidia's greatest strength (AI) also potentially its undoing?
Someone
2 days ago
> Google's limitation is that they still don't offer TPUs in a PCI-E card/dev board that people can plug in to their PC for local development
I’m not familiar with this field, but to my brain, https://www.amazon.com/s?k=Google+Coral seem to show me several such options.
spwa4
2 days ago
... with performance greater or comparable to even the lowest performance Nvidia card?
robocat
2 days ago
> Google's limitation is that they still don't offer TPUs in a PCI-E card/dev board
Nvidia's sells hardware yet their market cap is about the same as Google's.
How much value could Google get by selling hardware too? Google'd be selling to competitors, so difficult to capture much of the value and would decrease Google's value as an AI company. Maybe a child company?
bdangubic
2 days ago
Google sells TPUs already, to competitors :)
HeWhoLurksLate
2 days ago
I mean they had/have the Coral but that's in an entirely different market segment
bigyabai
2 days ago
Coral and the TPUs are ASICs, and therefore are barely reprogrammable. It doesn't really compare to the complexity and flexibility of CUDA ALUs.