3 ms·
> The performance of any application on SYCL is currently quite poor. SYCL can get pretty much equivalent performance in Kernels to eg. CUDA. Try looking at SY
by hjabird 3y ago
> The performance of any application on SYCL is currently quite poor.
SYCL can get pretty much equivalent performance in Kernels to eg. CUDA. Try looking at SYCL performance papers on Arxiv. Eg. see [1].
That isn't to say that SYCL code is optimised on every platform without tweaking - you do still need to put effort into target specific optimizations to get the best performance, like you would in the CUDA or HIP.
> Why drop ROCm (used on the world's largest supercomputer?)
Some of the world's largest super-computers / HPC applications do use SYCL for AMD! The application I'm most aware of for this is GROMACS. As to why? - because having 3 version of the same code using different programming APIs is a big maintenance burden.
[1] https://arxiv.org/pdf/2309.09609.pdf https://arxiv.org/pdf/2309.09609.pdf
- arcanus 3y ago> Some of the world's largest super-computers / HPC applications do use SYCL for AMD! The application I'm most aware of for this is GROMACS. As to why? - because having 3 version of the same code using different programming APIs is a big maintenance burden. The fact that GROMACS is unwilling to drop CUDA support to stand fully behind SYCL is very telling.
- hjabird 3y agoI wouldn't expect them to drop CUDA support, even if SYCL is a viable alternative: * The CUDA backend is mature, featureful, and significant effort has been invested into optimising it on Nvidia hardware. One does not simply throw away a performant, well validated HPC code! * Nvidia GPUs dominate the GPGPU market - unlike AMD's. * The SYCL backend is still is very new in comparison (they even state in the docs to pay extra attention to validation), and doesn't have Nvidia-specific optimisations yet. Why prioritise reimplementing what already exists?