AdaptiveCpp 24.02 Released: "One Of The Best SYCL Compilers" For Performance

[phoronix]

Phoronix: AdaptiveCpp 24.02 Released: "One Of The Best SYCL Compilers" For Performance

AdaptiveCpp 24.02 is out this week as the newest version of this SYCL compiler formerly known as hypSYCL and Open SYCL. AdaptiveCpp supports C++-based heterogeneous programming models targeting all major CPU and GPU vendors thanks to SYCL and C++ standard parallelism...

https://www.phoronix.com/news/AdaptiveCpp-24.02-Released

[FuchtelJockel]

This sounds very exciting. Now we only need someone teaching this at university instead of cuda.

[aviallon]

This sounds very exciting. Now we only need someone teaching this at university instead of cuda.

So fkin true.

[illuhad]

This sounds very exciting. Now we only need someone teaching this at university instead of cuda.

AdaptiveCpp supports SYCL and C++ PSTL offloading as programming models. At my university, depending on the course, SYCL is taught along other models like CUDA.
C++ PSTL offloading even is promoted by NVIDIA too.

[ddriver]

Not touching SYCL till they throw a hammer in there!

THB, hot a big fan of those "automatic" solutions. I prefer to retain control that surrender it to have some "easy" blackbox solutions.

Heck, I don't even use std::vector, this stuff has like 50% overhead for around a cacheline of data. And that's actually "good" compared to QVector, which has around 70% overhead in that scenario. And that's just a sequential vector, things get much much uglier for the more computationally complex stuff.

Out of the box solution suck. And this project's existence seems to be an out of the box solution automatically shoehorning more out of the box solutions into the gpu pipeline. Sounds like a great idea! I am sure it is easy, but it is a safe bet it will be nowhere nearly as good as a manual and well thought out solution.

[Zyten]

This sounds very exciting. Now we only need someone teaching this at university instead of cuda.

I agree that the recent advancements of AdaptiveCpp sound really exciting. There are two things I don't like about SYCL though. First, one is limited to writing C++ code. In the HPC space, there are still many programs utilizing Fortran, Julia or Python (or even C). For those, one can use CUDA, HIP or, depending on the language, even OpenMP target and OpenACC. The same is true for Kokkos.
In addition, there is no interface for performance tools. This is a general issue of the SYCL standard. One can get information via CUPTI and so on, but this hides all the stuff of the SYCL runtime itself.

[Eirikr1848]

This sounds very exciting. Now we only need someone teaching this at university instead of cuda.

Or… we need ZLUDA on AdaptiveCPP and SYCL?! 👀

[illuhad]

Not touching SYCL till they throw a hammer in there!

THB, hot a big fan of those "automatic" solutions. I prefer to retain control that surrender it to have some "easy" blackbox solutions.

Heck, I don't even use std::vector, this stuff has like 50% overhead for around a cacheline of data. And that's actually "good" compared to QVector, which has around 70% overhead in that scenario. And that's just a sequential vector, things get much much uglier for the more computationally complex stuff.

Out of the box solution suck. And this project's existence seems to be an out of the box solution automatically shoehorning more out of the box solutions into the gpu pipeline. Sounds like a great idea! I am sure it is easy, but it is a safe bet it will be nowhere nearly as good as a manual and well thought out solution.

I have no idea what you mean. SYCL can be as low-level as you want, to a similar level as CUDA. Do you think that CUDA is "too automatic" as well?

I also have no idea what you mean with your comment about "out of the box solutions". AdaptiveCpp has its own, unified LLVM-based JIT compiler infrastructure. There is nothing easy or trivial about it. Yes, it uses LLVM. Are other LLVM-based compiler projects (which includes basically any modern compiler like AMD hipcc or Intel DPC++) guilty of this "shoehorning" as well?

I agree that the recent advancements of AdaptiveCpp sound really exciting. There are two things I don't like about SYCL though. First, one is limited to writing C++ code. In the HPC space, there are still many programs utilizing Fortran, Julia or Python (or even C). For those, one can use CUDA, HIP or, depending on the language, even OpenMP target and OpenACC. The same is true for Kokkos.
In addition, there is no interface for performance tools. This is a general issue of the SYCL standard. One can get information via CUPTI and so on, but this hides all the stuff of the SYCL runtime itself.

The Kokkos and SYCL models are fairly similar in terms of their interface. The kind of Fortran bindings that Kokkos has should also be possible to build for SYCL. I think the models will have similar interop implications: Sharing data between Fortran and Kokkos/SYCL and controlling runtime functionality should be possible via Fortran-C++ interop. Actually defining kernels inside Fortran code is going to be equally hard.
And don't forget that SYCL is one of the Kokkos backends.

My opinion is that it does not have to be SYCL's job to save all of the world. There is a demand for C++ heterogeneous computing, and SYCL attempts to fill this niche. It does not have to be a solution for everyone. The core idea behind SYCL is: What if we took the programming language, and expressed heterogeneous parallelism in a way that is natural and idiomatic for this programming language?
The advantage of this approach is that you get something that integrates very well and feels natural for programmers. The downside is that it cannot be directly ported to other programming languages, because what is natural or idiomatic there might be completely different. So you would potentially need a very different solution.

However, I believe that to make progress with heterogeneous programming, the heterogeneous programming model must be integrated as a first-class citizen into the programming language, and not added in as an afterthought, which OpenMP or OpenACC sometimes feel like. SYCL is trying to do this for C++. The Fortran people will have to come up with their own solution if they want to have something like this.

Point taken about a unified interface for tooling.

[dwagner]

Can someone name a prominent example software written in SYCL that demonstrated its strenghts?