In my opinion they don't tackle exactly the same needs.

If I have the choice, I have an nVidia card and plan to run code mostly on a CPU, I strongly prefer CUDA since the control code is way simpler. Plus, it has some ways of utilizing specifically some of the nVidia architecture "gimmicks".

However, sometimes you need some code that is portable among different devices (although the high performance quality is not SO portable itself).

After all, OpenCL is just a standard definition that is as good as the implementation that you are using and how taylored is for the architecture you plan to utilize.

Thank you for your opinion, Miguel!

Hello, Ankur! Thanks for your opinion. However, OpenCL will never always be a better option. I have worked with both of them and was able to realize that, for instance, CUDA is better for solving large and sparse linear systems. Furthermore, it is possible to note that OpenCL, despite being an open standard may be considered more complex than CUDA in relation to programming. Therefore, the choice may depend on the problem to be solved.

I don't think one can generally say that CUDA is better at solving linear systems, only that the current CUDA implementations are better than the current OpenCL implementations. In some cases OpenCL code can be as performant as CUDA code, but there's no guarantee.

If platform portability is key then OpenCL is worth looking at, if you're happy to use Nvidia hardware and are focussed on performance then CUDA is probably the better option. As for me, I use both!

Cuda is proprietary to Nvidia and hence limited. OpenCL attempts to do something new. It provides the basis for heterogeneous parallel systems  - this simply means that it is built to handle mulitiple hardware suppliers with different compilers , and different parallel devices. It already includes multi-core and GPU (I have, for example, run the same kernel on both a radeon GPU (AMD) and multi-core phenom processor (AMD). Altera have demonstrated that their FPGAs, normally programmed using VHDL via their Quartus 2 modelling tool which is quite difficult, can be programmed with OpenCL kernels and these are built (albeit in a offline manner ) with Quartus 2 automatically applied. CUDA is fine for the specific GPU hardware . But OpenCL should be seen as the way forward  - it's the consortium way forward with many major companies supporting it. Having said that microsoft may be trying to present its own solution,ie  C++ Accelerated Massive Parallelism or C++ AMP.  Avoid proprietary solutions, they tend restrict the development of the idea, and lock people into one supplier.

Both CUDA and OpenCL work fine on GPUs which are enabled for those tools there is really very little issue as to which is best for that basic use. Note that for parallel tasks which are IO limited the choice of the GPU might be more appropriate. As heterogeneity becomes more significant hardware architecture will dominate - NVidia GPUS are limiting. And note that Intel has spotted this with its XEON Phi co-processor  - so NVidia may become beleaguered - then  CUDA will fade away.

CUDA will run on Nvidia GPU's which contains low cost RISC type of processors. Open GL targets GPU/CPU cores ( CISC type ). If the code that u want to run in parallel has a lot of complex code then prefer OpenGL, and if the parallel codes are more of mathematical calculations then CUDA can be preferred  over Open GL. CUDA is dedicated to Nvidia hardware only. In my experience CUDA is more faster than OpenGL. Open GL is not very much aware of all the performance features (Hardware) available on the Nvidia GPUs.

Mark Mawson, thanks for your opinion. Nevertheless, I did not say that CUDA is always better than OpenCL for solving linear systems. In my case, I was able to show that CUDA was better and more appropriate, only that.

John David Sanders, I appreciate your answer. This point of view is very clear and OpenCL seems to be a more useful tool in the future. However, I have published a paper in this year that demonstrates CUDA is still preferred by most researchers.

Bishwajit Pal, unfortunately you did not understand the topic of the question. I have worked with CUDA and OpenCL (NOT OpenGL), and my intention was to provide a discussion about this issue and try to understand the opinion of others researchers.

OOPS...! My bad....Didn't noticed that it was Open CL and Not Open GL.

Hey did you notice that Bordallo started his comments with "they don't tackle exactly the same needs". Naturally, if you want high speed graphics, perhaps you can use CUDA, but not double precision. Calculation, is kind of slower. and some cards give single precision. Quote; what are you looking for?

Hello, Victor! Thanks for your answer. As you can read in my last answer, my intention was to provide a discussion about this issue and try to understand the opinion of others researchers. Any comment would be welcome and appreciated.

Cuda vs OpenCL is to me a question of whether to use a homogeneous architecture to solve a problem or a heterogeneous one. While GPUs alone are good for massive parallel tasks they can be surpassed in efficiency by CPUs for tasks with a lot of dependencies. In that direction FPGAs are excellent in fixed point operations, linear algebra etc.

So the answer is linked to how complex your application is and if you want to take advantage of different architecture by modularizing it. I would go for OpenCL in this case, while opting for CUDA for simple highly parallel monolithic applications.

With heterogeneous architectures emerging I think that at the end approaches like OpenCL which offer some sort of interoperability will prevail as a choice for programmers and engineers.

Hello, Marc! Thank you for your answer. I appreciated it.

I think this debate is quite similar to DirectX vs. OpenGL. The only difference is that DirectX is bound to a single operating system, whereas CUDA is not. Both DirectX and CUDA are proprietary solutions whereas OpenGL and OpenCL are open standards (actually, both managed by the Khronos Group).

The question is really about your goals. Do you want maximum performance? Then CUDA might be the best choice. Updates for CUDA occur quite often supporting the most recent features of NVIDIA GPUs. But, you have vendor lock-in and can only use NVIDIA cards. Looking at other discussions, AMD graphics cards can provide "more bang for the buck", especially when it is about double precision operations. NVIDIA graphic cards artificially reduce the bandwidth for double precision computations. So, if you want to use CUDA with double precision you need to buy TESLA compute cards. These are more expensive. In summary, depending on your problem and if maximum performance (i.e. every last percent) is of your concern (and money is not) then CUDA is the best choice.

If you don't buy a new graphic card once a year to get the best performance or you don't have the money for an expensive card, OpenCL (and maybe AMD) is a valid alternative. Also, if you don't spend too much time on optimization and don't learn every new language/GPU feature as soon as it comes out, there is not much of a performance difference between OpenCL and CUDA in general.

My choice is really simple: I've chosen OpenCL. The reason for this is that I'm writing commercial software which should work with the hardware the client already has. He should not be forced to buy an NVIDIA card. Furthermore, hardware as old as back to 2010/2012 should still be supported, which means that I cannot use modern hardware features. With these restrictions there is not much of a performance difference between CUDA and OpenCL. But, the good thing is that I don't have to write my code twice--once for the GPU and once for the CPU. OpenCL kernels will support the CPU as well. (The reason for this is that even if a client does not have an OpenCL-capable GPU the software should still work.)

Looking at the battle DirectX vs. OpenGL, OpenGL has a good chance to win in the long run as Valve is switching to OpenGL and starts bringing out their own operating system SteamOS. The reasons are portability and compatibility. For the same reasons OpenCL might win over CUDA in the long run. Not now, but maybe 10-20 years from now. OpenCL will not die because it is necessary for Mac OS and for AMD hardware. The question is if NVIDIA will fight for CUDA the same way as Microsoft does for DirectX. In my opinion the cost of DirectX for Microsoft is already too high.

I agree with Simon Schröder that this debate looks much like the ever lasting DirectX vs OpenGL debate (or, in general, a proprietary vs open platform).

I will not repeat here the pros and cons, as other participants in this discussion have well described. Instead, I'll point out what I consider to be one important issue to consider when choosing the platform, from the developer's point of view (that is - if the developer can choose).That issue is the maturity of a platform. By that I mean how long has a platform been used by the community without major compatibility problems (like some strange OpenGL driver issues we could see during the first half of the previous decade). In order to be sure that an OpenCL program works fine on all platforms, one actually has to test it (and possibly to measure the performances) on every platform. The "fun" part comes when tests show incompatibility issues.

I've chosen the CUDA path, back in 2009, after reading some posts and articles claiming that OpenCL was still immature. Since then, CUDA has evolved quite a lot, and I think we could say that it has reached a high level of maturity. Now, it would be nice if someone in this discussion could confirm the maturity of OpenCL - and by maturity I mean cross-platfrom stability and consistency. I guess that this answer will give a clue whether it is currently worth making short term investments in OpenCL.

Hello, Simon and Dorde! Thank you for spending your time to answer this issue. I think that your opinion is very important to this debate. I have worked with both. Particularly, I chose CUDA because it is simpler for me in relation to programming and the problems which I deal. On the other hand, as Simon told us, I also think that OpenCL may be a better choice in a near future due its portability and the possibility of parallelism exploitation in CPU too. For now, I just prefer to assert that the choice depends on the problem to be solved.

I would give OpenACC a try...

Lauro, my point still stands. The implementation of CUDA you used was more performant than the OpenCL implementation you used for the specific problem you tackled. Nevertheless, I'd be interested to see your work as I find these kinds of comparisons very interesting.

Hello, Mark! There some papers in my profile that show this issue. Please, make yourself confortable and take a look at them. If you have any question, please let me know.

Best wishes!

Mark, it is true that probably the differences are because the CUDA implementation used was more performant than the OpenCL implementation.

However, since both CUDA and OpenCL implementations for nVidia cards are done by the same vendor (nVidia) it is likely that it will always be like that. OpenCL defines an standard that nVidia must implement, while CUDA can change as much as they want to adapt to the particularities of their HW. Plus, they have no interest on having an OpenCL implementation that works better than their controlled product.

As I say before, they are not "really" the same thing. While OpenCL is the standard for heterogeneous computing that CAN be used on GPUs, CUDA is a taylor made language and implementation made specifically to exploit the architectural benefits of nVidia cards.

So, if you have the chance of working with just an nVidia card, portability is not an issue and you want performance, simple control code and easy development, the maturity and specificity of CUDA is probably the way to go.

When portability is an issue, it is always better to use a standard. However, an interesting fact on the portability of OpenCL is that while the a big part of the same code (mostly the kernels) can be certainly executed in several platforms, the high performance will not be as portable. There will still be a need of making optimizations to exploit the architecture at hand. A code optimized for a GPU does not necessary work as optimized on a multicore ARM or FPGA. Also the control code is likely not 100% portable and must be re-written when changing the platform to a totally different one.

@Miguel: Even though OpenCL is meant for heterogeneous computing that CAN be used on GPUs, there is not much of a difference to CUDA. When you look at kernels for both CUDA and OpenCL you have the same features available (except for the most recent hardware features available in CUDA). The kernel code will look almost the same. Also the kind of data transfer is the same. Only the means of writing the control code are different. OpenCL looks more like a language for GPGPU computing than anything else. Everything in the language is targeted for GPUs.  There are some minor tweaks in addition to that so that OpenCL kernels also run on different platforms. To exploit architectural benefits of nVidia cards you have to write your OpenCL kernels accordingly (e.g. AMD had good support for vec4 whereas nVidia breaks them down to 4 scalars). In addition to that OpenCL allows for vendor specific extensions so that nVidia could (I don't know if they do) add support for every new hardware feature to OpenCL themselves. The only disadvantage of this is that this makes it non-portable in the end.

I have to agree with Mark that it is most likely that the two algorithms for CUDA and OpenCL are not comparable. Even though the CUDA compiler probably produces slightly better optimized code, you should not see a significant difference in speed between the two implementations.

OpenCL would be ideal, but it seems that CUDA is always ahead of the more open and general standard, so I continue to use CUDA myself.

Hello, Sam! I have to agree with you. I still continue using CUDA too.

For HPC, adopt CUDA (requirement NVIDA GPU). For portable applications (any graphics card or other processors, including CPU), choice OpenCL. In terms of examples, samples, tools, and so on, CUDA is ever one step ahead.

The discussion is quite long, so I'll try to stick to things that have not been mentioned yet.

First off, I settled on OpenCL, simply because I don't like to support a single-vendor solution for compute.

At their core, there is no huge difference in the capabilities of CUDA and OpenCL. There is definitely a difference in the libraries available to high-level users. If you are programming kernels yourself, then coding in the two is actually very similar, as the architectures are abstracted in a similar way. As far as performance, recent studies consistently show similar performance for well-written kernels (sorry, no handy links). But if you want to use GPU compute without having to learn GPU programming, CUDA is better at the moment with a set of mature high-level libraries. On the OpenCL side, things have been getting better, with AMD introducing clMath and Bolt and third-party libraries like ArrayFire, but we have still a ways to go.

There are some other differences that may matter to some people - for example, you cannot do dynamic kernels in OpenCL like you can in CUDA (looks like that's in OpenCL 2.0). But I can't think of any that are of the make-it or break-it type. They might make a difference for solving some very specific problems.

So for me the choice today stands as do you pick the extra convenience (and potentially development speed) of CUDA or the wider support and the idea of open standards of OpenCL. I fully understand why lots of people gravitate towards CUDA, considering how much more you can get for free from their libraries. I just wish that more people would invest their time in getting the OpenCL ecosystem to the same level, so that we can have a first-choice common standard.

CUDA for performance, OpenCL for portability...

Regarding the performance difference between OpenCL and Cuda for solving large linear systems, I think there might be some confusion in vocabulary in some answers.

I think it is important to differentiate between

• the OpenCL / Cuda  implementation by the hardware manufacturer , which involves for example  the compiler's aptitude at generating high-quality machine code
• a linear system solver implementation, which involves both a choice of algorithms, and implementation of said algorithms

For my probem, before embarking on a full code development, I tested a typical algorithmic operation which I needed to perform, both in Cuda and in OpenCL; performance was virtually identical.

On the other hand, the Cuda environment has better-developed linear algebra tools, such as CuBlas, which may allow faster linear algebra operations for a number of cases. This is not however due to Cuda, but to the library used. I believe the same algorithm correctly programmed in OpenCL and executed on the same hardware would almost always perform just as well.

This can actually be verified with some third-party libraries which have equivalent implementations of algorithms, in both languages. MAGMA/MAGMAcl  is one example.

I don't really know C++, but know C. For me, that is the difference. CUDA is based on C, so I am comfortable with it. 

Have you snoop around,  http://wiki.tiker.net/CudaVsOpenCL

"CUDA vs OpenCL: Which should I use?"

Thansk Lauro for initiating this discussion! I personally decided to go for openCL for my next project due to it's portability to different hardware setups. For me it is more important that the outcome of my work is available to as many as possible.

Even though I feel that coding in openCL is a bit more tedious especially in the beginning. From the Kernel perspective I agree with others here, that the they are pretty much the same, it's just a question of terminology for the most. 

The key advantage of OpenCL from my viewpoint is that kernels created can target a wider variety of not only operating systems, but also underlying computer architectures.  For example, my research group is working on computer vision transformation kernels that we intend to test on FPGAs, GP-GPUs, and multi-core microprocessors.  With CUDA, the same kernel would have be to adapted from FPGA or multi-core implemenatations (modified).  We'd prefer direct comparison of unchanged kernels rather than say comparison of a transform written in Verilog to one written in CUDA.  With OpenCL, we can do this - it can target a wide variety of parallel architectures that provide concurrency with different underlying compute elements.  Some downsides are that OpenCL kernels that target FPGAs are for example very costly to compile and synthesize compared to traditional HDLs, but I suspect improvements will come over time.

Others have already given many good answer, I just want to add another perspective and support the claims by showing a survey. Please see my following paper which provides extensive survey of CPU-GPU heterogeneous computing techniques. Table 3 of this paper summarizes which programming language has been used for GPU and CPU in heterogeneous computing research and we find that CUDA is used most prominently for GPUs in CPU-GPU heterogeneous systems, much more than OpenCL. The papers cited can give you more insights.

Article A survey of CPU-GPU heterogeneous computing techniques

In my experience CUDA can be a little more finicky to redistribute as others have said different hardware setups and cuda versions can be an issue. I've found that since CUDA is developing relatively quickly, there's a real issue with requiring the user to update their systems*  From the little I've seen C++ AMP is kind of meh and can have issues scaling up. 

The TL;DR is CUDA for max speed, OpenCL for redistribution. 

*http://docs.roguewave.com/totalview/8.14.1/html/index.html#page/User_Guides/totalviewug-about-cuda.31.4.html

http://docs.roguewave.com/totalview/8.14.1/html/index.html#page/User_Guides/totalviewug-about-cuda.31.4.html

I use CUDA and find it quite useful for GPU work with NVIDIA - e.g. Tegra K1, Tesla/Fermi.  However, it's NVIDIA specific of course, so it's not so great if your goal is to compare different co-processor architectures - the goal of my research group at CU Boulder and Embry Riddle.  We use OpenCL for our work on power efficient computer vision transform co-processing because we can more easily and directly compare one OpenCL transform implementation on the Tegra K1, Altera DE1-SoC FPGA and Multi-core / Many-core systems such as Intel MICA.  The one drawback is that not all OpenCL compilers are mature yet - for example, the compilers for FPGA that also synthesize a bit-stream do work reliably, but they are very slow.  There are minor porting details between say the Intel OpenCL compilers, Altera and NVIDIA, but one can basically compare the exact same implementation on all 3 co-processor platforms and this is great!  It has really helped our research effort and I think is the correct vision for the future - to allow portability between co-procesors with an open language to exploit different options for parallel co-processing.  I suspect Intel, NVIDIA and Altera will continue to improve their OpenCL support and this is much appreciated.

CUDA

I am not sure that in future of Heterogeneous Parallel systems the GPU will be a significant hardware solution. Even with OpenCL starting to free us from the difficulties of using FPGAs  (ie Altera). The FPGA and its software toolset is also evolving and that means that configurable hardware now at the gate levels is becoming the new way and the tools are reaching to helps us. 

see http://www.eetimes.com/author.asp?section_id=216&doc_id=1327664

CUDA , OpencL , AMP  and others  are at unit level of architecture  - the fpga is at gate level - it is likely to win. 

GPUs tend to be I/O bound and this often restricts their usage  - FPGAs  can be used to channel independent streams of data for roles such as signal processing. If as I suspect that the academic world will continue to use CUDA and OpenCL  for research reasons then they may find that the  commercial will skip both in favour of inexpensive FPGA products which with right tools they can now use.  The prudent thing is to anticipate this trend to keep students in the game.

I really wish this discussion was still going on.

Nevertheless, just to share my experience (from 2015 up to now);

I prefer OpenCL, with one main reason being the affordability of the compatible hardware. For me, things started out as a passion project, and a $150 AMD card for my home computer did the trick. Even at this price, I would not only get support for double-precision operations, but also GDDR5 memory.

Article Application of the discrete element method for the simulatio...

My wish is that a solution like Intel Xeon Phi multiprocessor (not co-processor) becomes more mainstream and efficent because it simplifies greatly the porting of shared memory parallel codes toward many more cores.   At the present times it is not obvious which solutions will win in the future, but the portability issue is certainly an important aspect on the long term.  

Here is some different discussion point to make .

1. if my code consist of { int a; float b; double c; } the efficiency of calculation speed drops a lot depending on hardware ( NVIDIA vs AMD) so for a entry level graphic card I do not see any clear line where using GPU is better than using multicore CPU for double type calculation. Personally think AMD Firepro is more favorable in that regard offering almost 1:1/2 ratio.

2. Problem of 1 is more obvious that NVIDIA graphic card driver only support OpenCL 1.2 where OpenCL 2.2 is available on AMD card. yeah sound like a good plan to make CUDA look better by intentionally delaying OpenCL support performed by market domination? Because of this clumsy decision made by NVIDIA I can pull out all my NVIDIA card and sell it on Ebay and purchase Firepro and get full OpenCL 2.2 support. plus ECC memory comes with free just in case your server got hit by unlucky solar particles.

3. (a) NVIDIA only make GPU card so they develop CUDA in a hope that people use more GPU over CPU so that they can sell more => they have to drive toward.. "no CPU but just GPU calculation only" . (b) AMD make both CPU and GPU so they support OpenCL => " guys we can use both GPU and CPU" (c) Intel were making only CPU but other two guy were shouting "GPU computing" so Intel made Xeon phi. Probably they had to pick a OpenCL side as a CPU maker.

given (a) (b) (c) in the market,   Nobody wants to die then

For now OpenCL is the only way to make all wins which it seems to me NVIDIA guys already figured out by unwillingly supporting old version of OpenCL on their graphic card.  However it is hard to predict a~c's next move although c has more moves to make at their position.

To have tried the Xeon Phi alternative I find that ignoring the OpenCL/CUDA debate and using OpenMP on traditional C/C++/Fortran old codes leads to a much faster effective use of old codes than adapting them to CUDA/OpenCL.   One important advantage of the Xeon Phi processor (KNL) over GPU's is the direct access to memory, so the codes are not limited to 8-16 GB for fast memeoy access, but the computer memory, which can go up to 384GB.   I

In parallel computing the raw speed is not a good benchmark, what counts is the FLOPS/$, because usually what is limiting the global performance is the amount of money a project can afford.  So the first question is what computing speed (FLOPS) can be reached by this amount of money?   The second question is often: what time do I need to adapt the code to the new hardware?   If it is years instead of months the raw speed advantage of the new hardware is less compelling. 

My opinion is CUDA is better than Opencl for the kernel code.

this link investigates the differences

https://arxiv.org/vc/arxiv/papers/1005/1005.2581v1.pdf

I think most researchers prefer cuda than opencl

A comparison from 2013 at:

https://www.iwocl.org/wp-content/uploads/iwocl-2014-tech-presentation-Jianbin-Fang.pdf

CUDA... NVIDIA starts the game before others and the result is more mature API.

If your software need to be very flexible and adapt different hardware, OpenCL is more suitable. If your hardware is fixed and it is Nvidia, then develop in Cuda will worth the effort. So depends on your need.

CUDA is the best one. OpenCL is a template and very difficult to code. CUDA is the Programmable GPU language.

A good comparison of OpenCL and CUDA is presented here

https://wiki.tiker.net/CudaVsOpenCL/