Is any plan to develop and merge dpct library like cuda_runtime_api.h?

[alanzhai219]

As we all know that sycl/sycl.hpp is not very friendly if we compare it with cuda_runtime_api.h. We always code a long long function to get some results, right? for example

• cuda: warpSize
• sycl: it.get_sub_group().get_local_range().get(0) Do you think it looks elegant? It looks very obscure. We should avoid hard code in the design but sycl spec has lots of hard code 0/1/2. So I create some macro to replace it. https://github.com/alanzhai219/sycl_help_header/blob/main/sycl_help_api.hpp

In order to help developers understand and develop the sycl quickly, why not design a runtime level api like nvidia's cuda_runtime_api does?
Looks dpct has implemented some of these esay-used api but not enough.
How do you think about it?

[JackAKirk]

I completely agree. Please open this as an issue in the most appropriate repo (sycl spec repo): https://github.com/KhronosGroup/SYCL-Docs/issues

[alanzhai219]

@JackAKirk Thanks for your reply.

1. I have filed a same-titled issue Is any plan to develop and merge intel dpct library like cuda_runtime_api.h? KhronosGroup/SYCL-Docs#578.
2. But I am pessimistic. That is because the open source organization is always imcompact. I remain skeptical about their execution capabilities. As an open source organization, they have to consider other vendors besides intel, so this process is naturally very slow.
3. As a commercial company, Intel is fully capable of building a runtime API based on dpct, with SYCL as the underlying layer and C and C++ as the upper layers. Without a doubt, this is the most efficient and fastest approach. That is not hard at all!
4. Believe it or not, some developers complain that there is no C API for sycl.
5. Most developers are not very experienced. Programming language should be simple instead of complex to learn. If a programming language is popular, it must be simple to learn and apply. At least, the API name should be clear and simple.

[JackAKirk]

On your point about open source considering other vendors: It is different point to the one you make on complexity, but I believe an important thing to consider is that a language at the higher level of sycl (or at least how sycl is adopted for oneapi) needs to be designed primarily around the requirements of 99.5% applications for highly parallelized computing (and the commonly used application domains that satisfy this constraint are actually incredibly narrow, and then even different such application domains have strong mathematical (and therefore computational) commonalities. At this level differences in vendor hardware don't matter so much. And it is important for sycl to support nvidia/amd/cpus to be competitive.

I think your point is more about the complexity of sycl compared to a C API rather than the scope of sycl being too broad (although I think the two are related). In any case I agree with most of your points about developers that actually work in domains requiring highly parallelized codes not being specialist software engineers and that this hasn't been taken into account enough.

I think that the only way to change it is to encourage such developers to also speak up. This is the only way that you can expect change to happen more quickly.

Thanks