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

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

import array же

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

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

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

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

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

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

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

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

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

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

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

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

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

openCL, python, java

Жесть-то какая! На чистых сях (ну или плюсах) проще всего же!

Тогда используй C++. питон тебе не упростит задачу.

И да, s/openCL/CUDA/ (т.к. во-первых, проще; во-вторых, быстрее; в-третьих, реально работает, в отличие от.)

ok

[лорсовет] [python] [java] Что выбрать для openCL? (комментарий)

На чистых сях

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Java, для OpenCL юзай LWJGL, полная поддержка, интероп с OpenGL есть

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

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

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

игровой движок?... это не из пушки по воробьям? :)

Да и openGL мне ни к чему.

Он просто качественный, места ведь не жалко?

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

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

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

Этот очень доделан

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

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

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

...или numpy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А я тут ещё наткнулся...

http://www.jcuda.org

Правда, это для CUDA а не для OpenCL

Привет.

Тут 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. на дворе ну и т.п.

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

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

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

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/...

Реаниматор, блин!

Если бы на этом форуме была ЛС - написал бы т-щу vertexua в ЛС.

А так даже контактов в его профайле нету :(

Я тут, но занят эти два дня очень. Потом напишу

привет.

таки просветишь чуть подробнее, чем lwjgl оказался удобнее остальных трёх вариантов?

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

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

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

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

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

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

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

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

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

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

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

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

«Параллельные вычисления на 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 можно просто забыть.