Consider providing an alternative to the monolith `sycl/sycl.hpp` header

[AlexeySachkov]

Extension Type

New Feature

Feature Description

sycl/sycl.hpp is the only header file that is documented by the SYCL 2020 specification meaning that users pay for everything in it even if use a small fraction of features. The cost is compilation time here.

The situation gets even worse with the addition of multiple extensions and what's even more concerning: KHR extensions do not propose their functionality in form of separate headers and their adoption is expected to go wider than just a single vendor implementation. They could even be included into the new versions of the core specification, thus introducing compile-time impact on everyone!

I will be talking about this issue on the upcoming IWOCL 2025, but I'm recording it here to be able to give a reference point for this issue in my slide deck.

Give me a week or so and I get back to you with more details and potentially a proposal of a potential sycl.hpp split.

To better illustrate the problem, take any compiler, your favorite SYCL implementation and compare compilation time of an empty file which includes bits/stdc++.h (non-standard header that includes all C++ STL) vs compilation time of an empty file that includes sycl/sycl.hpp.

Related Functionality in C++

C++ is designed with "you don't pay for what you don't use" in mind and therefore their standard library is split into separate headers so that user only includes what they actually need, without being forced to wait for parsing and analysis of effectively dead code.

Related Functionality in Other Languages

No response

Related SYCL Extensions

No response

[TApplencourt]

@ye-luo propose that a first start, maybe we can split device / and host header.

[AlexeySachkov]

@ye-luo propose that a first start, maybe we can split device / and host header.

I believe that a similar idea was expressed by @illuhad in our talks at IWOCL 2025, but I'm not sure how it would work. SYCL is advertised as a single-source program where both host and device code reside in the same translation unit. Does it mean that we will ask users to refactor their code to keep device and host code in separate translation units?

I mean, that happens in huge applications/frameworks/libraries, but the most benefit of fine-grained header is visible in small applications which are not (yet, or ever) structured that way.

In any case, stay tuned, an extension document draft is already in the works and it should be posted for review soon

[ye-luo]

I meant at least separating the host runtime APIs like device/memory management stuff.

[illuhad]

I believe that a similar idea was expressed by @illuhad in our talks at IWOCL 2025, but I'm not sure how it would work. SYCL is advertised as a single-source program where both host and device code reside in the same translation unit.

Yes, this was also my idea. Some thoughts:

• Some change in the source code to benefit from this feature will be necessary in all cases anyway (in the best case, just replacing #include statements)
• For small code bases, compile time is perhaps less of an issue (excluding of course RTC, but I'm skeptical about the whole approach of using SYCL source code for RTC in the first place)
• For large code bases where compile time is perhaps more critical, it is likely that you will have large parts of code that will just need host-side stuff to do device management, data management, queue construction, event sychronization etc. Kernel code tends to be a small fraction of the overall application in most cases I've seen. In this case, just providing a header for host code will be very useful.
• Libraries: I'm also aware of use cases where people just want to be able to define library APIs without pulling in all of the SYCL device library. If you imagine e.g. a SYCL BLAS library, you might want to forward-declare some event gemm(queue&, float* in1, float* in2, float* out) function which will then be implemented in the source file of a library. But of course, you'd like to shield your users from having to include all of sycl.hpp just to get the library interface. For such a library use case, a host-header will also be useful and directly usable. (maybe even better might be a header with forward declarations of runtime classes?)

[AlexeySachkov]

The wait is over, the proposal is live in #814