Learn SYCL* in an Hour (Maybe Less)

// this is a sycl USM memory allocation
auto d4 = (int *)sycl::malloc_shared( sizeof(int)*200, myQueue2 );

And get rid of the accessors (outAccessor and myD4f) since USM can just use pointers. You can replace the declarations with these macros instead (being lazy and not wanting to edit the actual usages):

#define outAccessor d4
#define myD4 d4

Offloading Computational Works to Accelerator(s)

We can simply write some code and say, “Run this code on the accelerator.” This is a simple Hello World! that runs on an accelerator.

q.submit([&](sycl::handler& cg) {
           auto os = sycl::stream{128, 128, cg};
           cg.single_task(
                            [=]() { os << "Hello World!\n"; });
         });

The submit says we have work to offload. The single_task is used to specify a single thing to run; in this case, a print of Hello World! The single_task can specify a function to offload, but often we just specify it inline using a C++ lambda function (as I have done in this case).

Since accelerators are used to gain performance through parallelization, we need something a little more involved if we want to do anything for higher performance. This is when we need to know that SYCL emphasizes a style of programming that invokes a kernel in parallel. This is the same programming style you find in CUDA and OpenCL. The idea is simple: We write a kernel that can be simple serial code to operate on one piece of data, and then we invoke it in parallel such that a kernel is invoked on each data element independently.

In the sample code, we actually do a blur in parallel. Understanding that code is not particularly hard, and once we understand it SYCL really starts to make sense. Here is a simpler look at going parallel by simply making Hello World! run in parallel:

// this is the entire program

#include <sycl/sycl.hpp>
int main(int argc, char* argv[]) {
  sycl::queue q;
  std::cout << "Running on "
            << q.get_device().get_info<sycl::info::device::name>()
            << "\n";
  q.submit([&](sycl::handler& cg) {
             auto os = sycl::stream{1024, 1024, cg};
             cg.parallel_for(10, [=](sycl::id<1> myid)
                 {
                   os << "Hello World! My ID is " << myid << "\n";
                 });

         });
}

Running on my laptop, under WSL, it printed this:

Running on Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz
Hello World! My ID is {5}
Hello World! My ID is {0}
Hello World! My ID is {7}
Hello World! My ID is {2}
Hello World! My ID is {1}
Hello World! My ID is {8}
Hello World! My ID is {6}
Hello World! My ID is {9}
Hello World! My ID is {3}
Hello World! My ID is {4}

The Example Program

Now you know plenty to go off and explore. Keep in mind that a queue connects to an accelerator, and uses of the queue will then be either to set up data sharing or to offload computations. That should be enough to puzzle out the sample program and start changing it to experiment and learn more.

The sample program that I provided online is my own mess. It is intended only to show off the basics with absolutely no regard for writing an effective parallel program. I think all the other learning resources for SYCL in the world try to show well-considered parallel programming examples. I wanted to be different and inspire fun exploring to get started.

The sample program does three different jobs. Each job will run on one of three different accelerators when available, or they will happily run all on the host if that is all we have, or whatever mix of accelerators we find at runtime.

I pulled together this code so that I could show a variety of things that are easy to change and understand. I believe that has high value when starting out. You will even discover that part of the code has if-defs to change between using buffers and USM for sharing for one of the examples if you wander over to the Exercise_02_... subdirectory.

Two notable extras in the code that I tossed in to encourage more playing while learning valuable techniques:

• I create an array of queues and load them up with all the accelerators that I can find. Then I take the first, second, or third accelerators for the three different jobs (modulo the actual number of accelerators we found at runtime). Do not be thrown by the seeming complexity of this silly code: It is not doing much of anything different than simply creating a queue with sycl::queue q;. It does hint at more fun you can have in selecting your favorite accelerators at run time, and possible matching them to custom algorithms if you like. So much fun available — but not necessary to learn SYCL.
• I set up the queues with profiling selected. (I assume it is available, which it usually is, but this limits where we can run the program unless we spend a little more effort and add logic to only use profiling on devices that support it.) The profiling option lets us gather information about the actual run times on the accelerator. This is more valuable than wall-clock time when tuning our kernels because it helps reduce noise caused by other code if all we are doing is tuning the kernel itself. Together, kernel timing and wall-clock timing give us great data while we tune an application.

Once you are comfortable with SYCL, we can learn much more from the resources listed at sycl.tech, including a book that I co-authored, some examples and tutorials, and much more.

Summary

We learned two key things: (1) SYCL fundamentally addresses three things for using accelerators from C++, and (2) we have a silly little program we can get lost in for hours changing and experimenting with as our first SYCL program.

I believe it Is highly valuable to know as many programming models/languages as we can so we can use the appropriate tool for the job. If our job is writing C++ that uses accelerators, and the kernel style of expressing parallelism makes sense for our algorithm, and we want our application to be highly portable across vendors and/or architectures, then knowing SYCL could well be valuable.

Learning SYCL is not hard at all. Mastering effective parallel programming … Well, that is a whole different matter.😊

Happy coding!