Future of OpenCL?

Question

The OpenCL programming paradigm promises to be a royalty free opens standard for heterogenous computing. Should we invest our time in developing software based on OpenCL? Pros/cons?

Answer 1

The question is too broad and vague to be really be answered. However, I do see one notable point against OpenCL, from the point of view of scientific computing, which is rarely emphasized. So far, there has been no effort to produce open source, infrastructure libraries for OpenCL, whereas CUDA has several excellent options:

• CUBLAS, CUFFT, CUSPARSE
• Thrust, Cusp, OpenCurrent
• PETSc support

I believe this will really hurt OpenCL since a major facilitator of adoption is high quality, open libraries.

Answer 2

OpenCL vs what?

If the question is OpenCL vs CUDA, I see a lot of hand-wringing over this question, and it seems crazy to me. It doesn't matter. Honest. The kernels - where all the hard thinking has to go - are practically identical between the two languages; you could write macros for your favourite editor to do 99% of the work to bounce between OpenCL and CUDA. It has to be that way; they're low-level control of ultimately pretty similar sorts of hardware. Once you've figured out how to write your important kernels in {OpenCL,CUDA}, it's trivial to port them to {CUDA,OpenCL}.

The boilerplate host code you have to write is similar, too, but CUDA keeps simple cases simple. That's why we teach CUDA in our centre; you can leap straight into writing kernel code, whereas we'd have to spend 1-2 hours of our daylong course just explaining the kernel launching stuff for OpenCL.

But even there the difference isn't that important; once you start doing more complicated thing (asynchronous kernels on multiple gpus), they're both equally complicated and again you can pretty much do a line-by-line translation from one to the other.

If it's OpenCL vs the directive-based approaches -- OpenACC or HMPP or something -- those are probably (hopefully?) going to be good ways of programming these kinds of architectures in the future, where you can get 90% of the performance for 10% of the work. But which choice will "win" remains to be seen and I wouldn't recommend spending a lot of time working with those just yet.

So I'd say, between CUDA or OpenCL pick a language that's convenient for you and use it, and don't worry too much about it. The valuable part - figuring out how to decompose your problem into massively-parallel SIMD code for small cores with very little memory - is going to be pretty easily portable between programming models.

If you're using NVIDIA hardware - and you probably are - then I typically recommend CUDA - Matt Knepley's point about the libraries is dead-on. If you're not, then OpenCL.

Answer 3

Whether you should invest your time in developing software based on OpenCL is a question only you can answer. If it looks like it has the potential to solve the problems you are facing right now, and no other open solution does, your best course of action is probably to take a risk on implementing a small project with it.

If that goes well, you can try it with larger projects and so on until you either build up enough confidence to standardise on it, or discard it in favour of some other solution (which might be your own proprietary solution, another open solution or even another proprietary solution).

The wonderful thing about the open source movement is that because you have the source you have everything you need to fork the project if necessary. Even if the community itself doesn't give you the facilities you need, there's nothing stopping you implementing those facilities yourselves. Also, if you wanted those facilities, there is a distinct possibility that other users might want them, so would appreciate it if you contributed those changes back to the core project.

Not only that, but if you make it better from your perspective, it might make it better for others, encourage them to submit their own enhancements and ultimately make the software better for everyone.

Finally, yes this is a rather generic answer to rather a generic question. To answer more fully, we need to know what your concerns over OpenCL are. Is it maturity? Community support? Ease of use? Time needed to learn? Time to develop? Changing your procedures? When you ask about the Pros and Cons, which other products are you attempting to compare OpenCL to? What research have you already done? What features do you need to support your heterogeneous computing environment?

Answer 4

One big PRO is the number of vendors behind OpenCL. I have some anecdotal experience about this, having met a research group that spent a large amount of time and effort to develop a fairly complicated CUDA code for an NVIDIA powered system. A year later after the code was developed, the research group got access to a larger and faster AMD based system but they could not use it as they did not have the (human) resources to port the code.

Even if the core set of features of CUDA and OpenCL are almost identical (as @JonathanDursi well pointed out), if the original developer is not the one assigned with the task of converting the code, the whole porting project can be quite time consuming.

However, there are some official incompatibilities between CUDA and OpenCL. Most remarkably CUDA support c++ templates while OpenCL does not yet officially support them. However, there is an effort made by AMD to develop an extension to OpenCL with support for templates and other C++ features, more information in this post from AMD dev central. I hope a future revision of OpenCL might add this work.

At this point in time (early 2012), the awesome libraries that @MattKnepley links to are closed source or use templates, so they will not become available for hardware other than NVIDIA, at least in the mean time.

For someone that is learning gpu-computing, I would say that OpenCL C can be quite difficult, as there are a lot of details that distract the learner from the basic ideas, whereas CUDA is simpler and straight forward. However, there are tools that make OpenCL much more simple to learn and use like PyOpenCL (the python wrapper for opencl) which brings all the python sugar to OpenCL (note that there is also a PyCUDA). For instance, the PyOpenCL demo for adding two arrays is just under 25 lines and it includes: creation of the arrays on host and device, the data transfers, the creation of the context and queue, the kernel, how to build and execute the kernel, getting the results from the GPU and comparing them against numpy (see links below).

PyOpenCL -- http://mathema.tician.de/software/pyopencl

PyCUDA -- http://mathema.tician.de/software/pycuda

For experienced gpu-programers, here I agree with @JonathanDursi, CUDA and OpenCL are fundamentally the same and there are really no mayor differences. Moreover, the hard work of developing an efficient algorithm for GPUs is very much language independent, and the OpenCL support from vendors and the documentation is now much more mature than say 2 years ago. The only point that still makes a difference, is that NVIDIA is really doing some great work with their support to the CUDA community.

OpenCL has the added benefit that it can run on CPUs and is already supported by Intel and AMD. So you don't need to change your algorithmic framework if you want to take advantage of any available CPU cores. It is not my opinion that OpenCL is the best solution for a single CPU / multicore oriented application as a CPU optimized kernel might look significantly different than a GPU optimized kernel. However, in my experience CODE development does benefit from being able to run on the CPU.

Answer 5

I think OpenCL is currently suffering from a lack of a "champion". For example, if you visit the NVIDIA site right now (12/16/2011), you've got several "Ken Burns Effect" style shots on the splash page focusing on the scientific/industrial side of GPU computing, and ~1/4th of your navigation options point you toward things that will probably end up at CUDA. Manufacturers selling "GPU computing" servers and workstations are selling NVIDIA solutions.

Competing offers from ATI are mixed in with the general AMD site, harder to find, and not as heavily featured in third-party solutions. Those solutions, and the ability to do OpenCL based programming certainly exist, but it's left a perception - at least in my mind, but in the minds of some other folks I've talked to - that the OpenCL platform's big corporate sponsors have already "quit the field". People using OS X for example, are all probably too busy speculating about whether or not a Apple workstation will even exist in a year to have faith in them pushing OpenCL GPU computing.

Answer 6

The most important factor is that CUDA will remain supported only by NVIDIA hardware.

Thus, if you want to make robust and portable software, OpenCL is the only option. At most you can build around some currently CUDA-powered libraries and hope they will get extended over OpenCL in future pulling your code with it.