Гетерогенные вычисления с использованием OpenCl Vs java

Question

Java и OpenCL поддерживают гетерогенные вычисления; системы с множественной архитектурой, работающие совместно параллельно (задача и данные параллельны).

Переносимость является главной целью в обоих случаях, и обе они достигли этой цели в значительной степени. На самом деле OpenCl не может быть запущен на FPGA и DSP, поскольку инструменты недоступны. JVM может быть разработан для графических процессоров FPGA, ARM и т. Д.

Оба генерируют промежуточный код.

Несмотря на такое многообразие, почему и когда следует отдавать предпочтение OpenCL над Java для гетерогенных вычислений?

EDITED

Пожалуйста, конкретно на мой вопрос: Несмотря на столь много общего, почему и когда следует предпочесть OpenCL над Java для гетерогенной вычислительной техники? Почему вообще я выбрал OpenCL вместо Java? Если вы говорите, что openCl имеет лучшую производительность, то мой непосредственный вопрос будет объясняться тем, почему это так (поскольку оба генерируют промежуточный код, который необходимо преобразовать в двоичные файлы для определенных h/w).

Answer 1

OpenCL обычно используется для обработки больших объемов параллельных операций (расчеты и т. Д.). Именно здесь OpenCL процветает, и пропускная способность вашей программы действительно увеличивается.

Java - это язык общего назначения для написания приложений, работающих на разных платформах/устройствах.

Они имеют другую цель в качестве инструментов, но вы можете использовать OpenCL из своей Java-программы, используя JOCL. Я также использовал инструмент из AMD под названием Aparapi. потому что я хотел, чтобы мое приложение выполняло некоторые вычисления, работу, которую моя карта ASUS AMD 6970, казалось, выполнялась быстрее, чем мой 6-ядерный AMD 1090T Phenom Black Edition.

Просто, чтобы вы знали, что Aparapi это (взято из google code site):

Aparapi позволяет разработчикам Java, чтобы воспользоваться преимуществами вычислительной мощности из GPU и APU устройств путем выполнения данных параллельного фрагмента кода на GPU, а не ограничивается локальным процессором. Он делает это с помощью , преобразуя байт-код Java в OpenCL во время выполнения и выполняющий на графическом процессоре , если по какой-либо причине Aparapi не может выполнить на GPU, он будет выполнять в пуле потоков Java.

---

Несмотря на столь много общего, почему и когда следует предпочесть OpenCL над Java для гетерогенной вычислительной техники?

Можно было бы выбрать OpenCL для задач параллельной обработки, которые в противном случае потребовали бы много времени для выполнения на CPU. Недостатком в этом случае будет дополнительные затраты на тепло и энергопотребление. Помните также, что некоторые задачи будут выполняться быстрее на процессоре. Все зависит от приложения, которое большую часть времени потребует испытаний на обоих типах чипов, чтобы решить, какой из них лучше всего подходит.

Почему вообще я выбрал OpenCL вместо Java?

Можно было бы выбрать OpenCL над Java для задач, ориентированных на параллельную обработку. OpenCL - это инструмент, созданный для этой цели. OpenCL - это не то, что вы хотели бы использовать для создания корпоративных или настольных приложений. Java - это язык программирования практически для любого домена, работающего на многих платформах. Если бы вы знали, что использование OpenCL позволит им экономить 24 часа на вычисления по Java; Разумеется, Java была бы обойдена, и OpenCL мог бы пойти или просто OpenCL мог быть использован через Java-приложение.

Если вы говорите, OpenCL имеет более высокую производительность тогда мой непосредственный вопрос будет, почему это так (так как генерировать промежуточный код, который нужно быть преобразованы в исполняемые файлы для конкретной ч/б).

Он имеет лучшую производительность для конкретных приложений, поскольку у GPU больше ядер, чем у процессора. Часто их частота довольно низкая, поэтому это означает, что они лучше работают на параллельных задачах, а не на последовательных. Вы должны помнить, что OpenCL используется для базовых вычислений, а не для создания приложений с полным вкусом ... по крайней мере, насколько я знаю.