LINUX.ORG.RU

[лорсовет] [python] [java] Что выбрать для openCL?

 ,


0

3

Писать на C++ и использовать openCL считается довольно сложным, в принципе, я с этим суждением и согласен. Хотя наверное необходимую мне программу осилю и на плюсах, но потрачу больше времени.

В связи с чем спрашиваю, что лучше использовать, python или java? Слышал что-то про библиотеки pyopencl и javacl (или что-то похожее), в каком они сейчас состоянии? Насколько качественные (удобные в использовании)?

Сначала python привлекал своей внешней простотой, а сейчас немного отталкивает некоторой запутанностью. вот и думаю, что выбрать... Например, массивы являются частью языка java, в то время как в python приходится использовать библиотеку numpy (не списки-же), что немного усложняет дело...

Плюсы я знаю плоховато, python и java чуть получше.

Возможно, я в чём-то не прав, потому сильно ногами не бейте ;)

в python приходится использовать библиотеку numpy (не списки-же)

import array же

Norgat ★★★★★
()

Ты думаешь, что если api opencl завернуть в python, то он от этого проще станет? Нифига подобного. А если тебе нужна простота и вычисления на видеокартах, то используй cuda.

Reset ★★★★★
()

Например, массивы являются частью языка java, в то время как в python приходится использовать библиотеку numpy (не списки-же), что немного усложняет дело...

Питон в принципе не предназначен для числодробилок (или для чего Вам там массивы то понадобились?). Кстати я как то тестил - аррай питоновский еще тормознутее чем список. На питоне пишется верхний управляющий слой и интерфейс, все вычисления требующие больших ресурсов пишутся на С/С++/фортране/паскале-еще-чем-нить быстром-но-сложном-в-использовании и цепляются к питону в виде модулей, а питон уже этим хозяйством рулит. С openCL думаю так же надо работать, т.е. дергать из питона низкоуровневые вызовы openCL довольно бессмысленно...

Ява вроде пошустрей питона, но до С++ все равно не дотягивает (чудес то не бывает), так что все равно придется в связке работать. Мы юзаем связку питон-С++.

AIv ★★★★★
()
Ответ на: комментарий от Reset

Согласен с вами. cuda малец попроще будет. Как в освоении, так и в использовании. Но так уж получилось, что надо openCL, решение не за мной ;)

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от AIv

Да, не предназначен =) для того и разработали numpy/scipy.

java тоже не предназначена для числодробилок. Тут C/C++ самое оно.

т.е. дергать из питона низкоуровневые вызовы openCL довольно бессмысленно...

Речь же об этом и не идёт... там вызовов то раз два и всё... а вычислений довольно прилично.

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от AIv

Там принцип такой... ищется устройство, если оно есть - создаётся контекст, потом очередь. потом загружается программа, компилируется и передаётся на устройство (GPU) то бишь.

А после этого выполняется какое-нибудь ядро (или все сразу). А собственно эти ядра и выполняют всю ёмкую работу.

Ну или какую-то работу выполняют numpy-array. Чтобы они быстро работали, надо всего-лишь навсего работать с ними не напрямую, а используя специальные методы...

Вот только я начинаю склоняться к мысли, что использовать C++ и массивы может оказаться проще. %( чем копаться в документации по numpy. А pyopencl использовать вроде несложно (хотя вот сам opencl может и сложнее).

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от Eddy_Em

На чистых сях

Смотря что (кроме шуток)

BattleCoder ★★★★★
() автор топика

В общем всем спасибо за советы. Не буду усложнять себе жизнь. Буду учить плюсы =)

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от BattleCoder

Проблема в том, что OpenCL мало того, что сложнее, чем CUDA, так еще и тормознутее в большинстве случаев.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Аргументом в пользу использования OpenCL от моего научника выступило то, что она более переносима. =)

Хотя о переносимости говорить тоже не приходится... ибо я так пока и не нашёл способа запустить openCL-код на моём ноутбуке, где нет nvidia-карточки (только intel-вская размазанная), а там, где nvidia есть - всё равно он работает только на GPU (хотя из описания OpenCL следует, что он должен запускаться и на CPU)

В моём случае лучше наверное написать две программы, решающие мою задачу на OpenCL и на CUDA. Вот только python вы использовать не советуете, только C++?

Pure C использовать не хочу потому что использование классов должно (в теории) упростить код. Сейчас разгребаю код, который уже написан кое-кем другим (мне надо написать аналогичное, используя другой алгоритм), хоть он и написан на python (и даже использует классы) - настолько он запутанный, что мама не горюй %(

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от BattleCoder

Аргументом в пользу использования OpenCL от моего научника выступило то, что она более переносима. =)

Толку от нерабочей переносимости?

Если действительно нужно ООП, то лучше, конечно, плюсы использовать. Просто у меня нет и не было ни одной задачи, где ООП было бы нужно использовать - поэтому все у меня на голых сях.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Раз уж пошла такая тема... давно хочу купить печатный вариант книжки по CUDA, электронный вариант есть, но его не так удобно читать. Желательно опять же на русском.

Какая из этих двух лучше?

http://www.nvidia.ru/object/cuda-books-ru.html

И насколько хорош перевод первой книги (рассматриваю вариант покупки и оригинала) ? вторая вроде русская...

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от BattleCoder

давно хочу купить печатный вариант книжки по CUDA

Это бесполезная трата денег. Намного дешевле распечатать на принтере и сшить книгу. Все равно через год-другой уже подустареет и выйдут новые расширенные версии мануалов.

P.S. На русском языке вообще брать не надо - бородатый баян.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Это бесполезная трата денег. Намного дешевле распечатать на принтере и сшить книгу.

Для этого надо купить принтер, что выйдет дороже... а распечатать где-то на заказ тоже небось выйдет дороже чем так купить...

И сомневаюсь, что такое подустареет =)

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Да вроде нет...

Ну вообще да... тот же pyopencl явно недоделан... до сих пор python3 не поддерживает например. по поводу других java биндингов даже не знаю.., но сомневаюсь как-то.

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от BattleCoder

Хороший принтер стоит тысячи четыре. Если печатать не 100 страниц в год, получается очень даже выгодно.

Eddy_Em ☆☆☆☆☆
()

Смотрю вот биткойн-генераторы. Один на чистом C. Много на Python. Один на Java. Тот что на Python использует модули Nymphy, Twisted, Web2 и самое главное - pyopencl.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

это ни о чём не говорит, практически

anonymous
()
Ответ на: комментарий от AIv

На питоне пишется верхний управляющий слой и интерфейс, все вычисления требующие больших ресурсов пишутся на С/С++/фортране

...или numpy

tailgunner ★★★★★
()
Ответ на: комментарий от AIv

А что, numpy позволяет тело цикла из питона опустить на уровень С-й?

Операция умножения матриц - это опускание цикла или нет?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Если грамотно сделана, то конечно да. Но это очень частный, специфический случай... для неявных численных схем, где все затраты гл образом связаны с решением СЛАУ (обращением матрицы) такое наверное прокатывает. Для явных схем и задач хоть сколь либо актуального размера (не влезающих в кэш) уже нет - один цикл фактически разбивается на множество циклов, в каждом из которых делается одно элементарное действие (ну что туда заложено то и делается - сложение матриц, умножение матрицы на число и т.д.). В итоге локальность данных оказывается ни к черту, и производительность падает кардинально (сколько действий в теле одного цикла можно сделать, во столько раз и падает грубо говоря).

На С++ можно сделать на шаблонах аналогичную фиговину, где скажем пишешь

A = (B+C)*D+exp(E*U);

(A, B, C, D, E, U - массивы) и это все раскручивается в один цикл. На numpy наск я понимаю будет 6 циклов (я с ним не работал, но из общих соображений так).

AIv ★★★★★
()
Ответ на: комментарий от AIv

Да, умножение матриц это конечно не N операций. Но в явных схемах, где сложность O(N) все плохо будет;-)

AIv ★★★★★
()
Ответ на: комментарий от AIv

Для явных схем и задач хоть сколь либо актуального размера (не влезающих в кэш) уже нет - один цикл фактически разбивается на множество циклов, в каждом из которых делается одно элементарное действие (ну что туда заложено то и делается - сложение матриц, умножение матрицы на число и т.д.). В итоге локальность данных оказывается ни к черту

Для таких задач сделали numexpr.

На С++ можно сделать на шаблонах аналогичную фиговину, где скажем пишешь

A = (B+C)*D+exp(E*U);

(A, B, C, D, E, U - массивы) и это все раскручивается в один цикл.

Про это ХЗ. Теоретически, numexpr должен быть способен на такой трюк.

tailgunner ★★★★★
()
10 ноября 2012 г.
Ответ на: комментарий от vertexua

Привет.

Тут http://jocl.org/ помимо lwjgl есть ещё три варианта:

1) jocl (собственно онтопик сайта). написано, что типа не Ъ, не ООП-стиль, все функции static, зато в точности как OpenCL

2) некий JOCL from JogAmp.org - не понял, в чём отличие

3) javaCL, от nativelibs4java - из плюсов, есть «братский» проект scalaCL, но вроде как сильно недоделанный (на сайте так и сказано). ожидаю :) на scala приятнее писать, чем на java, более высокоуровневый он что ли.

Ну 4-й вариант - это lwjgl. Он действительно лучше трёх других? Смущает, это это game library :) openGL мне не нужен в ближайшее время, мне пока нужна только числодробилка (хотя в будущем можно будет подумать, например, о визуализации некоторых научных штук, может там openGL к месту будет, ток его тоже учить надо :) )

Извиняюсь, что тему разбудил =) просто стало внезапно снова актуально (всё это время голова была другим забита). Есть опыт реальной разработки на lwjgl чего-то полезного и работающего?

p.s. jcuda, к слову, не радует отсутствием maven-репы (чистая cuda тоже не радует сами знаете чем), присматриваюсь к биндингам java для cuda/ocl

p.p.s. python (pycuda/pyopencl) не радует своей динамической типизации, зависимостью кучи библиотек от 2.7 ветки, в то время как 3.2. на дворе ну и т.п.

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от vertexua

если есть jabber - стукни pkozlov <at> jabber <dot> ru

если время будет конечно =)

это к тому. если в жабер удобнее писать по каким-то причинам, чем сюда.

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от AIv

A = (B+C)*D+exp(E*U);
(A, B, C, D, E, U - массивы) и это все раскручивается в один цикл. На numpy наск я понимаю будет 6 циклов (я с ним не работал, но из общих соображений так).

Не факт что в один цикл будет быстрее. Exp возможно выгоднее считать отдельно.

http://software.intel.com/sites/products/documentation/hpc/mkl/vml/functions/...

ebantrop
()
Ответ на: комментарий от BattleCoder

Достаточно искоробочен, очень новая версия всех extensions, так как есть OpenGL, то нормальная интероперабельность OpenGL-OpenCL

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

а есть ли там случайные числа, получаемые на GPU?

в javacl есть что-то такое... но не очень допиленное.

или мне использовать java.util.Random и не париться? мне вообще это нужно для метода Монте-Карло.

В cuda есть библиотека curand - позволяет получать случайные числа как в памяти device, так и «прозрачно» копировать их в память host. Вообще так как случайные числа мне нужны для моделирования случайного процесса, а все расчёты на GPU - удобно было бы их сразу создавать на GPU (минимизировав таким образом задержки на передачу device <==> host).

Или может есть какое-то решение по генерации случайных чисел на opencl? (в javacl как и наверное в lwjgl нет никаких особых проблем использовать любой готовый opencl-код)

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от BattleCoder

а есть ли там случайные числа, получаемые на GPU?

Это надо в FAQ ) Нету. Их можно написать, вообще с нуля, например Mersenne twister. Если не нужны постоянно новые в цикле, то можно один раз нагенерить и передать с СPU. Зависит от задачи.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

в javacl получается, например, интересный вариант... я могу нагенерить из на GPU (даже не уверен, что это быстрее - может и медленнее - надо замерять, всё-таки это не такой уж «дорогой» алгоритм, к слову, там используется xorshift) - они сохранятся в host-памяти, и я буду отправлять обратно на GPU чтобы уже использовать. :) Даже смешно.

Думаю, не буду париться и буду использовать что-то попроще, на CPU. Ибо да, времени много не отнимает.

И да, написать можно и с нуля =) и xorshift, и mersenne twister... (что касается первого, вроде несложный, второй как-то сложновато реализован, но потрудиться можно, да).

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от BattleCoder

И насколько хорош перевод первой книги (рассматриваю вариант покупки и оригинала) ? вторая вроде русская...

«Параллельные вычисления на GPU. Архитектура и программная модель CUDA: Учебное пособие.» - эта изначально писалась на русском. На сегодняшний день это самый свежак, хотя, разумеется, ни про CUDA 5, ни про Kepler там ничего нет. Перевод этой книги на английский (с обновлениями) будет, дай бог, только летом. Лучшая литература по CUDA - это подкаталог «doc/pdf» в CUDA Toolkit, особенно CUDA C Programmer's Guide и CUDA C Best Practices Guide.

По теме. OpenCL-ядра всё равно придётся писать на уёбищном OpenCL, так что нет разницы, на каком языке будет «клей», который подготавливает и загружает данные, - на Java или на Python. И да, люто двачую CUDA во всех отношениях. Единственное преимущество OpenCL - портируемость - нивелируется тем, что портировать-то по сути не на что. AMD раньше обыгрывало NVIDIA на примитивных задачах (типа генерации биткойнов). С выходом Kepler про AMD можно просто забыть.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.