Python中的GPGPU编程

2

在我看来，PyOpenCL更接近于OpenCL的C绑定，而不是CLyther。

这意味着如果您已经知道OpenCL，或者计划将其他语言的实现移植到Python，那么PyOpenCL可能适合您。另一方面，CLyther似乎比PyOpenCL更“pythonic”，所以如果你更熟悉Python，那么所使用的习语可能会更容易理解。

它们都在测试版，所以你可能没有你想要的所有功能，并且可能有错误。

祝你好运！

来源

2010-08-11 06:32:10 KLee1

0

CLyther包含类似于OpenCL和PyOpenCL的C级绑定。

clyther是'pythonic'的一个事实，它也允许你传递和/或使用Python函数作为openCL设备/内核函数。

内嵌在你的Python代码，你可以写

@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)

来源

2010-08-11 15:54:52 srossross

11

的OpenCL由两个部分组成。有一个通常用C语言编写的主机端和一个用OpenCL定义的C的派生语言编写的设备端。此代码在运行时编译到设备（通常是GPU）。

CLyther试图抽象出所有东西。你用Python编写主机端代码。您将设备端代码写入Python的一个子集中（与Cython类似）。这是非常高的水平和易于使用。

PyOpenCL是从Python的OpenCL API的较低级别绑定。设备端代码是用OpenCL的C99子集编写的。它使您可以完全访问和完全控制OpenCL。很少被抽象掉。

我对这两方面的经验都是有限的，但我的印象是，一旦两者都成熟了，我宁可在大多数项目中使用Clyther。它更加用户友好，这意味着你更可能使用它，并更多地使用它。与PyOpenCL和Python相比，在Clyther和Python之间来回移动代码也更容易，因此代码维护和重构应该更容易。对于非常关键性能的项目，我更喜欢PyOpenCL。它可以提供更好的低级控制，并减少您与硬件之间的层次。 PyOpenCL的最终性能应该比Clyther更好。

我不知道这是否会永远如此。 PyOpenCL最终可能会添加更高级别的构造，而Clyther最终会添加更低级别的控件。在一个理想的世界中，Clyther开发人员会移动核心，使其构建在PyOpenCL之上，因此我们不必选择并避免重复劳动。不过，我怀疑这种情况会发生。

目前，PyOpenCL似乎比Clyther更成熟。它是从第一个开始的，而且范围不那么雄心勃勃。它比Clyther有更好的文档，并且似乎有更大的用户社区。两者在代码大小上相当类似 - Clyther大约是4KLOC的Python和4KLOC。PyOpenCL大约是7KLOC的Python代码和9KLOC的C++代码。这是近似的（包括构建系统，示例等），因此不应将其视为暗含超出近似平等的任何内容。

来源

2011-02-02 01:32:17 user274045

0

我觉得PyOpenCl和PyCuda很相似，它可以让你在内核端进行多种优化，这是GPGPU编程的有趣部分。

这是在C内核，而主机代码是Python化：

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

来源

2015-02-11 00:36:34 bakacoder

Python中的GPGPU编程

回答

相关问题