3 ms·

The difference between the kernel languages is minimal, many kernels can be translated with basic search & replace. The difference is in the scaffolding (CUDA

by rockdoe 10y ago

The difference between the kernel languages is minimal, many kernels can be translated with basic search & replace. The difference is in the scaffolding (CUDA is easier but less flexible), and pre-existing libraries on offer. If you're going to be writing the kernels yourself then it is easy to maintain both versions and it if it is for learning it doesn't matter at all (but I prefer the standard that works on all my machines).

pjmlp 10y ago
OpenCL doesn't do Fortran, C++, Haskell or .NET. Well, OpenCL 2.1 does do some C++ (not as much as CuDA with Pascal), but isn't widely available anyway.
- keldaris 10y ago
  There are plenty of zero-cost C++ wrappers available, including the official bindings. Most people who use OpenCL from C++ tend to accumulate their own convenience wrappers over time. The rest of those languages have fairly easy interoperability with C code and therefore access to the C api, though some may also have established convenience libraries. I wouldn't suggest .NET or Haskell for most serious GPGPU work, but Python, Julia, Fortran and others are frequently used. The PyOpenCL library is particularly excellent. If you were referring to the kernel language (a restricted subset of C99), I don't find that to be a disadvantage in practice. While CUDA supports a fairly useful subset of C++ (most notably, templates), I still find host-side metaprogramming to generate kernel code to be a much more useful approach in most cases. Of course your preferences may vary, but I haven't seen many experienced GPGPU people express dissatisfaction with this point.
- rockdoe 10y ago
  False. The official wrappers support C++ from OpenCL 1.0 on. Maybe this isn't obvious because the C++ bindings were introduced later, but they're backwards compatible and you can set the target API level. (And of course you use 1.2 if you need to support lagging vendors such as NVIDIA) I have no idea about the other languages but surely other bindings must exist?
  - pjmlp 10y ago
    No one is speaking of wrappers here, rather C++ kernels, which is what matters, a full C++ experience. > I have no idea about the other languages but surely other bindings must exist? Yeah, the usual poor man's solution of generating C code, thus introducing two compilation steps, without any debugger support.

by rockdoe 10y ago

pjmlp 10y ago

OpenCL doesn't do Fortran, C++, Haskell or .NET. Well, OpenCL 2.1 does do some C++ (not as much as CuDA with Pascal), but isn't widely available anyway.

keldaris 10y ago
There are plenty of zero-cost C++ wrappers available, including the official bindings. Most people who use OpenCL from C++ tend to accumulate their own convenience wrappers over time. The rest of those languages have fairly easy interoperability with C code and therefore access to the C api, though some may also have established convenience libraries. I wouldn't suggest .NET or Haskell for most serious GPGPU work, but Python, Julia, Fortran and others are frequently used. The PyOpenCL library is particularly excellent. If you were referring to the kernel language (a restricted subset of C99), I don't find that to be a disadvantage in practice. While CUDA supports a fairly useful subset of C++ (most notably, templates), I still find host-side metaprogramming to generate kernel code to be a much more useful approach in most cases. Of course your preferences may vary, but I haven't seen many experienced GPGPU people express dissatisfaction with this point.
rockdoe 10y ago
False. The official wrappers support C++ from OpenCL 1.0 on. Maybe this isn't obvious because the C++ bindings were introduced later, but they're backwards compatible and you can set the target API level. (And of course you use 1.2 if you need to support lagging vendors such as NVIDIA) I have no idea about the other languages but surely other bindings must exist?
- pjmlp 10y ago
  No one is speaking of wrappers here, rather C++ kernels, which is what matters, a full C++ experience. > I have no idea about the other languages but surely other bindings must exist? Yeah, the usual poor man's solution of generating C code, thus introducing two compilation steps, without any debugger support.