Hacker News Reader

Comment by cherryteastain | Hacker News Reader

> What about rocm makes it fundamentally by design that much worse? And what about sycl makes it better?

The fact that SYCL compiles device code to SPIR-V instead of a device specific ISA like HIP for instance. The decision to do the latter, alone, is what causes ROCm to have support for a very narrow range of cards which significantly hampers adoption.

View on HN

That's implementation details. SYCL and HIP are programming languages (more specifically C++ dialects), ROCm is an implementation of HIP that uses machine code. Intel DPCPP/icpx is an implementation of SYCL that uses SPIR-V.

There exists a HIP implementation that also compiles to SPIR-V, chipStar. And one can in theory write a SYCL compiler that generates machine code (maybe with openSYCL's HIP/ROCm backend?)

The woes the author of the article or various posters in this thread are also side effects of "implementation details". I don't think anyone is critical of HIP as a programming language, as it's just a CUDA clone. Pretty much all complaints (crashes, perf issues, poor device compatibility) regarding HIP/ROCm pertain to poor implementation/execution, including the directly-emitting-device-specific-machine-code problem. AMD can't wriggle out of this one with that excuse.

Oh, I'm not using it to excuse the issues! All I'm saying is that if AMD implemented SYCL instead they'd probably turn it into an equally big mess.

I very much agree - and I think some people misunderstood what I was trying to say too - that was that I don't think switching to SYCL would fix any of the problems that rocm currently has.

I personally feel many of the problems with rocm are due to lack of investment and management priority - there is no "technical" solution to that as a problem. And swapping out parts of that stack will just exacerbate those problems are now they need to rebuild everything from scratch with their insufficient resources.

Reply on news.ycombinator.com