Why I Want Khronos OpenCL C++ for Devices

Print Friendly, PDF & Email

As you know, OpenCL is a standard for heterogeneous computing and developers such as myself completely understand the importance of standardization. There are many issues with OpenCL in its current form, but despite my criticisms I respect that it is a standard. My strict adherence to standards can severely limit my productivity, because at this point the only option I have to program OpenCL devices is OpenCL C.

There are people out there who really like C programming, and I understand many of their reasons. I personally find that I am very productive with C++, because I can use tools such as template metaprogramming, operator overloading, and classes to write concise yet efficient code. Despite my occasional frustration with C++, it allows me to work at a high-level of abstraction so that I can do things like design containers that change their implementation at compile-time based on type traits. Unfortunately, OpenCL C forces me to work at a level where my productivity is greatly compromised and it becomes time-consuming for me to develop OpenCL software.

AMD does have some form of C++ kernel language which I will not use, because the entire point of OpenCL is to maintain portability. Perhaps the AMD C++ kernel language can target OpenCL C, and I admit I have not really investigated this. Khronos needs to provide an official OpenCL C++ language so that developers such as myself can get on with being productive and delivering value to customers.

OpenCL will likely never implement standard C++, instead some form of OpenCL C++ will have to be provided. We can’t assume that the hardware will support virtual functions, and we probably don’t want to impose an unnecessary hardware requirement. I am quite happy to have templates, classes, operator overloading, inheritance, and everything else without virtual anything. Standard C++ must be restricted, and rather than relying upon potentially contradictory restrictions imposed by various vendors targeting SPIR themselves, Khronos must take on the responsibility for OpenCL C++ support so that everyone agrees upon the restrictions imposed.

If OpenCL C++ is provided, I am confident that I can leverage my OpenCL programming experience to develop beautiful containers and libraries.

Leave a Reply

Your email address will not be published. Required fields are marked *