GPGPU программирование на Python - PullRequest
4 голосов
/ 11 августа 2010

Я хочу начать GPGPU программирование на Python.Должен ли я начать с pyopencl или clyther?Какая разница?

Ответы [ 4 ]

11 голосов
/ 02 февраля 2011

OpenCL состоит из двух частей. Существует сторона хоста, которая обычно написана на C, и сторона устройства, которая написана в производной от C, определенной OpenCL. Этот код компилируется на устройство (как правило, графический процессор) во время выполнения.

CLyther пытается все абстрагировать. Вы пишете код на стороне хоста в Python. Вы пишете код на стороне устройства в подмножестве Python (аналогично Cython). Это очень высокий уровень и простой в использовании.

PyOpenCL - это сравнительно низкоуровневая привязка к OpenCL API из Python. Код на стороне устройства написан в подмножестве OpenCL C99. Это дает вам полный доступ и полный контроль над OpenCL. Очень мало абстрагируется.

У меня ограниченный опыт работы с обоими, но у меня сложилось впечатление, что, как только оба станут зрелыми, я бы предпочел использовать Clyther для большинства проектов. Это более удобно для пользователя, что означает, что вы будете использовать его чаще и чаще. Также легче перемещать код между Clyther и Python, чем PyOpenCL и Python, поэтому обслуживание кода и рефакторинг должны быть проще. Для очень критичных к производительности проектов я бы предпочел PyOpenCL. Это обеспечивает лучший контроль низкого уровня и меньшее количество уровней между вами и оборудованием. Максимально возможная производительность должна быть лучше с PyOpenCL, чем с Clyther.

Я не знаю, будет ли это продолжаться вечно. Вполне вероятно, что PyOpenCL, в конце концов, добавит конструкции более высокого уровня, а Clyther, в конце концов, добавит управление более низкого уровня. В идеальном мире разработчики Clyther переместили бы ядро ​​так, чтобы оно было построено поверх PyOpenCL, поэтому нам не пришлось бы выбирать и избегать дублирования труда. Я сомневаюсь, что это когда-нибудь случится.

В настоящее время PyOpenCL выглядит более зрелым, чем Clyther. Это было начато сначала, и является менее амбициозным по объему. Он имеет лучшую документацию, чем Clyther, и, кажется, имеет большее сообщество пользователей. Оба кода довольно схожи по размеру - Clyther составляет около 4KLOC для Python и 4KLOC для C. PyOpenCL - это около 7KLOC для кода Python и 9KLOC для кода C ++. Это является приблизительным (включает в себя системы сборки, примеры и т. Д.), Поэтому не должно рассматриваться как подразумевающее что-либо за пределами приблизительного равенства.

2 голосов
/ 11 августа 2010

Мне кажется, что PyOpenCL ближе к привязкам C для OpenCL, чем CLyther .

Это означает, что если вы уже знаете OpenCL или планируете переносить реализации с других языков на Python, то PyOpenCL может быть для вас. С другой стороны, CLyther кажется более «питоническим», чем PyOpenCL, поэтому, если вы более знакомы с Python, то используемые вами идиомы могут быть проще для понимания.

Оба они в бета-версии, поэтому у вас могут быть не все функции, которые вам могут понадобиться, и в них могут быть ошибки.

Удачи!

0 голосов
/ 11 февраля 2015

Мне кажется, что PyOpenCl похож на PyCuda в том, что он позволяет выполнять множество оптимизаций на стороне ядра, что является забавной частью программирования GPGPU.

Это ядро ​​в C, тогда как код хоста pythonic:

mod = SourceModule("""
__global__ void multiply_them(float *dest, float *a, float *b)
{
  const int i = threadIdx.x;
  dest[i] = a[i] * b[i];
}
""")
0 голосов
/ 11 августа 2010

CLyther содержит привязки на уровне C, аналогичные OpenCL и PyOpenCL.

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)
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...