4 ms·
I feel this is falling into the rewrite trap - rather than continuing to develop an existing but imperfect system, throw it all away for something that is unpro
by kimixa 3y ago
I feel this is falling into the rewrite trap - rather than continuing to develop an existing but imperfect system, throw it all away for something that is unproven and currently in a notably worse state.
What about rocm makes it fundamentally by design that much worse? And what about sycl makes it better? Rocm is already based on many standard shared OSS projects, like llvm and clang. Often the same ones SYCL stacks are based on. What about SYCL makes it so superior that it'll make up for throwing all the current work away?
- imtringued 3y agoMost likely the ability to run software on the GPU. When I last used ROCm I got both bad performance and it was prone to crashing.
- JonChesterfield 3y agoIt's really sensitive to the (Linux) driver/compiler/library versions all lining up. If you get the blessed Ubuntu kernel version and use it with the exact corresponding driver from dkms and the matching userspace version it's reasonably solid. If you use the driver in Linux upstream, whether you have a good time or a terrible one varies with the age of the userspace libraries you're pairing with it. I don't know what to do about this setup. I think it's an artifact of gearing testing towards "releases" of the entire stack with specific HPC operating systems in mind. To do this right, each component would need to be individually solid and deal with version/interface slip relative to other components, which means the cross product of testing patterns is rapidly infeasible. I'm thinking about it but don't see a solution yet.
- cherryteastain 3y ago> 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.
- ColonelPhantom 3y agoThat'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?)
- cherryteastain 3y agoThe 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.
- ColonelPhantom 3y agoOh, 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.
- kimixa 3y agoI 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.