CODEWITHSUNDEEP
pythonopencl
r00kie
r00kie

Reputation: 893

GPGPU programming in Python

I want to start GPGPU programming in Python. Should I start with pyopencl or clyther? What's the difference?

Upvotes: 4

Views: 2706

Answers (4)

Smalltalkguy
Smalltalkguy

Reputation: 399

I feel PyOpenCl is similar to PyCuda that it allows you to do the multitude of optimizations on the kernel side which is the fun part of GPGPU programming.

This is the kernel in C whereas the host code is pythonic:

mod = SourceModule("""
__global__ void multiply_them(float *dest, float *a, float *b)
{
  const int i = threadIdx.x;
  dest[i] = a[i] * b[i];
}
""")

Upvotes: 0

user274045
user274045

Reputation: 872

OpenCL consists of two parts. There is a host-side which is typically written in C, and a device-side which is written in a derivative of C defined by OpenCL. This code is compiled to the device (typically a GPU) at run-time.

CLyther attempts to abstract everything out. You write the host-side code in Python. You write the device-side code in a subset of Python (in a similar way to Cython). This is very high level and easy-to-use.

PyOpenCL is a comparatively low-level binding to the OpenCL API from Python. Device-side code is written in OpenCL's subset of C99. It gives you full access to and full control of OpenCL. Very little is abstracted away.

I have limited experience with both, but my impression is that, once both are mature, I would prefer to use Clyther for most projects. It is more user-friendly, which means you're more likely to use it, and to use it more. It is also easier to shift code back and forth between Clyther and Python than PyOpenCL and Python, so code maintenance and refactoring should be easier. For very performance-critical projects, I would prefer PyOpenCL. It gives better low-level control, and fewer layers between you and the hardware. The ultimate possible performance should be better with PyOpenCL than with Clyther.

I do not know if this will continue to be the case forever. It is likely that PyOpenCL will, eventually, add higher-level constructs, and that Clyther will, eventually, add lower-level control. In an ideal world, the Clyther developers would move the core such that it was built on top of PyOpenCL, so we wouldn't have to choose, and to avoid duplication of labor. I doubt that will ever happen, though.

At present, PyOpenCL appears to be more mature than Clyther. It was started first, and is less ambitious in scope. It has better documentation than Clyther, and appears to have a bigger user community. Both are fairly similar in code size -- Clyther is about 4KLOCs of Python and 4KLOCs of C. PyOpenCL is about 7KLOCs of Python code, and 9KLOCs of C++ code. This is approximate (includes build systems, examples, etc), so should not be treated as implying anything beyond approximate equality.

Upvotes: 11

srossross
srossross

Reputation: 1393

CLyther contains bindings at the C level similar to OpenCL and PyOpenCL.

clyther is 'pythonic' in the fact that is also allows you to pass and or use python functions as openCL device/kernel functions.

Inline in your python code you can write

@kernel
@bind('global_work_size' ,'a.size')
@bind('local_work_size' , 1)
def sum(a,b,ret):
    i = clrt.get_global_id(0)
    ret[i] = a[i] + b[i]

sum(clarray1,clarray2,clarray3)

Upvotes: 0

KLee1
KLee1

Reputation: 6178

It seems to me that PyOpenCL is closer to the C bindings for OpenCL than CLyther.

This means that if you already know OpenCL, or plan to port implementations from other languages to Python, then PyOpenCL might be for you. On the other hand, CLyther seems more "pythonic" than PyOpenCL, so if you are more familiar with Python, then the idioms used might be easier for you to understand.

Both of them are in Beta, so you might not have all of the features you might want in either, and there might be bugs in either.

Good luck!

Upvotes: 2

Related Questions