Hacker News

The difference between ROCm and CUDA is that when a consumer GPU is released by nvidia it's supported for CUDA for about a decade (1xxx series cards just dropped last year). When a consumer GPU is released by AMD it's not supported by ROCm till about a year after release and then it's supported for about 3-4 years. With the RX 580 there were only 3.7 years after release before ROCm support was pulled. I bought mine a couple years after release and so only had about a year and a half of ROCm. Never again.

Things might be different in enterprise but for consumer AMD GPU ROCm is a trap. It is a mayfly. Sure, you can try to run the cards unsupported but you're just multiplying the difficulty and maintainence burden. And nothing will just work.

Someone needs to stand up a benchmark suite for ROCM, this, and everyone else attempting it to really get the ball rolling here. SemiAnalysis could have a blast with this.

So is Spectral, which is mentioned in the headline of the article! As it says there:

> SCALE delivers nearly a 6x performance boost on AMD GPUs compared to using HIPIFY to convert CUDA code to AMD’s own ROCm environment

... whilst also running CUDA.

That sounds nice on paper, but you’re assuming Nvidia wants to play fair. Nvidia is never going to share future microarchitecture secrets, so the moment they drop a new chip and update the compiler, everyone playing the compatibility game has to start from scratch.

We actually support NVIDIA hardware, too.

In some benchmarks, SCALE beats nvcc, and we have compiler optimizations in the pipeline that will improve those numbers over time.

> If all you want is to be able to easily use non-NVidia hardware then high level tools like PyTorch already let you do that

Somewhat true, but, CUDA is significantly larger than PyTorch and there's more to Accelerated Computing than just those types of applications supported there.

> OTOH if you want to be programming close to the metal to achieve top performance then you are probably not using CUDA in the first place, and using some CUDA translation layer on non-NVidia hardware would be an even worse idea.

SOTA mlperf submissions use CUDA to achieve their high levels of performance.

It's not a "translation layer", it's a native, ahead-of-time compiler that makes full use of the native hardware features. Here's an example of a feature (Shuffles) being compiled to take advantage of native hardware instructions, resulting in speedups: https://scale-lang.com/posts/2026-01-19-optimizing-cuda-shuf...

On the contrary, it's great. Cuda is the single sane compute API and system, so I'll use it even if it means being vendor-locked. If my CUDA programs start running elsewhere without much intervention, that'd be amazing

> Ease of programming and a giant leap in performance is one of the key reasons for the CUDA platform’s widespread adoption

This, so much. Other platforms continue to ignore developer UX, but it's one of the main things that get's new users onboard and keeps old users around.

We're actually targeting all of it, and not just CUDA C++.

SYCL is probably the most up-to-date CUDA alternative for all intents and purposes, at least if one likes modern C++ style (and lambdas inside lambdas). Expose it as C and get bindings to any other language for relatively little effort as well since it’s just C++. With AdaptiveCpp you can also compile SYCL to CUDA so both ways work with the CUDA dialect (PCUDA).

SYCL, as well as AdaptiveCpp, is a relatively active project though and has been for several years, feeding into the C++ standards committee work and is supported by several large organisations, including US national labs and several European universities. I suppose it’s worth keeping track of for people in related fields.

I suppose it’s just really hard to beat the head start and ecosystem integration NVIDIA has with CUDA.

Actually we launched in 2024 and the last message in our discord is definitely not that: https://discord.gg/KNpgGbTc38

this is closest thing we have to "cuda on non-nvidia" hardware

Is tenstorrent building GPUs now, not just tensor processors?

You can skip the porting part.

A couple of years ago I evaluated both Vulkan and Cuda as a choice for future projects. I couldnt get anything done after a week in Vulkan, but had the test prototype project working after just a day in Cuda.

Needless to say, I'd never ever pick Vulkan for any project after that experience. It's just way to needlessly overengineered and bloated.

Unfortunately, Vulkan Compute doesn’t to all the things that OpenCL, SYCL, HIP or CUDA do.

Vulkan tooling is light years behind what CUDA offers in 2026, across programming languages, IDE tooling, graphical debuggers and libraries.

Ports are very often incredibly difficult and very time consuming.

One of the biggest complaints we hear from the industry is "we tried to port to X and we could never complete it".

An established codebase can have years of refinement. It will take time to achieve the same with the port.

And with our compiler, just using cuda is no longer putting urself inside the moat :)