4 ms·

SYCL is a better analog to Cuda than OpenCL, and Intel have their own implementation of that. Don't really see anyone writing anything in SYCL though, and when

SYCL is a better analog to Cuda than OpenCL, and Intel have their own implementation of that. Don't really see anyone writing anything in SYCL though, and when I looked into trying it out it was a bit of a mess with different implementations, each supporting their own subset of OSs and hardware. https://www.intel.com/content/www/us/en/developer/tools/oneapi/data-parallel-c-plus-plus.html https://www.intel.com/content/www/us/en/developer/tools/onea...

rbanffy 3y ago
I am unfamiliar with the implementation, but why would it be difficult to implement a Cuda-compatible software layer on top of other platforms? This would be the first step. Then, if we want to move away from Cuda into hardware that's as ubiquitous and performant as Nvidia's (or better), someone would need to write an abstraction layer that's more convenient to use than Cuda. I did play a little bit with Cuda and OpenCL, but not enough to hate either.
- pjmlp 3y ago
  Because that is an herculean task, given the hardware semantics, the amount of languages that target PTX, the graphical debugging tools that expose every little detail of the cards like debugging on the CPU, and the libraries ecosystem. Any Cuda-compatible software layer only has two options, be a second class CUDA implementation by being compatible with a subset like AMD ROCm and HIP effforts, or be compatible with everything always playing catchup. The only way is to use middleware that just like in 3D APIs, abstract the actual compute API being used, as man language bindings are doing nowadays.
- JonChesterfield 3y ago
  Worth noting that cuda seems prone to using inline ptx assembly and that latter is really obnoxious to deal with on other platforms. Implementing programming languages and runtimes is pretty difficult in general. Note that cuda doesn't have the same semantics as c++ despite looking kind of similar. Wherever you differ from expected behaviour people consider it a bug, and implementing based on cuda's docs wouldn't get you the behaviour people expect. Pretty horrendous task overall. It would be much better for people to stop developing programs that only run on a gnarly proprietary language.
  - pjmlp 3y ago
    CUDA was redesigned to follow C++'s memory model introduced in C++11, yet another compatibility pain point with other hardware vendors.
pjmlp 3y ago
SYCL builds on top of OpenCL, it is basically the reboot of OpenCL C++, after OpenCL 2.0 SPIR failure. Yet another example on how Intel and AMD failed to take up on CUDA.
- hjabird 3y ago
  SYCL isn't based on OpenCL. SYCL (SYCL-2020 spec) supports multiple backends, including Nvidia's CUDA, AMD's HIP, OpenCL, Intel's Level-zero, and also running on the host CPU. This can either be done with Intel's DPC++ w/ Codeplay's plugins, or using AdaptiveCpp (aka. hipSYCL, aka openSYCL). OpenCL is just another backend. It is also a very long way from OpenCL C++. The code is a single C++ file, and you don't need to write any special kernel language. The vast majority of SYCL is just C++, so -if you avoid a couple of features- you can use SYCL in library-only form without even any special compiler! This is possible for instance with AdaptiveCpp.
  - zozbot234 3y ago
    It's pretty much based on the same underlying featureset. Which is why trying to target Vulkan Compute from it is messy enough, whereas OpenCL is a natural target.
  - pjmlp 3y ago
    Now, but that isn't how it started after the OpenCL 3.0 reboot, where 3.0 == 1.0. Also some of that work, we have to thank Codeplay for, before their acquistion from Intel.
shihab 3y ago
> Don't really see anyone writing anything in SYCL though My work involves writing software that runs on many GPU platforms at once. So far we have been going through the Kokkos route, but SYCL is looking pretty good to me recent days. There is some consolidation happening in this space (Codeplay gave up working on their own implementation and merged with Intel). It was pretty easy to setup on my Linux machine for Nvidia card. Documentation is very good and professional, unlike AMD's, which can be frankly horrible at times. And Intel has a good track record with software. I genuinely believe if someone is going to dethrone CUDA, at this point SYCL (oneAPI) is a far more likely candidate than Rocm/HIP.
hjabird 3y ago
SYCL is gaining traction, especially in the HPC community since it can target AMD, Nvidia and Intel hardware with one codebase. A fun fact is the GROMACS (a major application for molecular dynamics, and big consumer of HPC time) recommends SYCL for running on AMD hardware!

rbanffy 3y ago

I am unfamiliar with the implementation, but why would it be difficult to implement a Cuda-compatible software layer on top of other platforms? This would be the first step. Then, if we want to move away from Cuda into hardware that's as ubiquitous and performant as Nvidia's (or better), someone would need to write an abstraction layer that's more convenient to use than Cuda. I did play a little bit with Cuda and OpenCL, but not enough to hate either.

pjmlp 3y ago
Because that is an herculean task, given the hardware semantics, the amount of languages that target PTX, the graphical debugging tools that expose every little detail of the cards like debugging on the CPU, and the libraries ecosystem. Any Cuda-compatible software layer only has two options, be a second class CUDA implementation by being compatible with a subset like AMD ROCm and HIP effforts, or be compatible with everything always playing catchup. The only way is to use middleware that just like in 3D APIs, abstract the actual compute API being used, as man language bindings are doing nowadays.
JonChesterfield 3y ago
Worth noting that cuda seems prone to using inline ptx assembly and that latter is really obnoxious to deal with on other platforms. Implementing programming languages and runtimes is pretty difficult in general. Note that cuda doesn't have the same semantics as c++ despite looking kind of similar. Wherever you differ from expected behaviour people consider it a bug, and implementing based on cuda's docs wouldn't get you the behaviour people expect. Pretty horrendous task overall. It would be much better for people to stop developing programs that only run on a gnarly proprietary language.
- pjmlp 3y ago
  CUDA was redesigned to follow C++'s memory model introduced in C++11, yet another compatibility pain point with other hardware vendors.

pjmlp 3y ago

SYCL builds on top of OpenCL, it is basically the reboot of OpenCL C++, after OpenCL 2.0 SPIR failure. Yet another example on how Intel and AMD failed to take up on CUDA.

hjabird 3y ago
SYCL isn't based on OpenCL. SYCL (SYCL-2020 spec) supports multiple backends, including Nvidia's CUDA, AMD's HIP, OpenCL, Intel's Level-zero, and also running on the host CPU. This can either be done with Intel's DPC++ w/ Codeplay's plugins, or using AdaptiveCpp (aka. hipSYCL, aka openSYCL). OpenCL is just another backend. It is also a very long way from OpenCL C++. The code is a single C++ file, and you don't need to write any special kernel language. The vast majority of SYCL is just C++, so -if you avoid a couple of features- you can use SYCL in library-only form without even any special compiler! This is possible for instance with AdaptiveCpp.
- zozbot234 3y ago
  It's pretty much based on the same underlying featureset. Which is why trying to target Vulkan Compute from it is messy enough, whereas OpenCL is a natural target.
- pjmlp 3y ago
  Now, but that isn't how it started after the OpenCL 3.0 reboot, where 3.0 == 1.0. Also some of that work, we have to thank Codeplay for, before their acquistion from Intel.

shihab 3y ago

> Don't really see anyone writing anything in SYCL though My work involves writing software that runs on many GPU platforms at once. So far we have been going through the Kokkos route, but SYCL is looking pretty good to me recent days. There is some consolidation happening in this space (Codeplay gave up working on their own implementation and merged with Intel). It was pretty easy to setup on my Linux machine for Nvidia card. Documentation is very good and professional, unlike AMD's, which can be frankly horrible at times. And Intel has a good track record with software. I genuinely believe if someone is going to dethrone CUDA, at this point SYCL (oneAPI) is a far more likely candidate than Rocm/HIP.

hjabird 3y ago

SYCL is gaining traction, especially in the HPC community since it can target AMD, Nvidia and Intel hardware with one codebase. A fun fact is the GROMACS (a major application for molecular dynamics, and big consumer of HPC time) recommends SYCL for running on AMD hardware!