Параллелизм Java: OpenCL / GPU против актеров / потоков
Проект APARAPI описывает себя следующим образом:
Aparapi позволяет разработчикам Java использовать преимущества вычислительной мощности GPU и устройств APU, выполняя фрагменты параллельного кода данных на GPU, а не ограничиваясь локальным процессором. Он делает это путем преобразования байт-кода Java в OpenCL во время выполнения и выполнения на GPU...
Мне интересно, Какие преимущества это дает по сравнению с традиционными фреймворками параллелизма, такими как gpars или Акка .
При каких обстоятельствах преобразование байт-кода JVM в OpenCL будет быстрее или предпочтительнее, чем то, что предлагают эти альтернативы? Почему парадигма OpenCL / GPU "быстрее" (по крайней мере, при определенных обстоятельствах), чем Java/CPU? Какие обстоятельства могли бы это оправдать?
1 ответ:
Я бы сказал, что akka-это очень высокоуровневая абстракция для параллелизма, в то время как такие вещи, как CUDA, OpenMP, MPI и так далее, предназначены для вычислительно дорогих вещей. Таким образом, akka отлично подходит для реализации чего-то вроде системы планирования задач и обработки и регулирования запросов, но не настолько хороша для выполнения самих задач, если они были вычислительно дороги и могли быть распараллелены. Но у вас есть эта действительно высокая абстракция и вы можете использовать фьючерсы с ними, чтобы сделать всю систему реактивный так, что он нигде не блокируется. Все библиотеки GPU отлично подходят для реализации массовых параллельных задач, где у вас есть куча дронов, которые делают почти одно и то же. Так вот, это что-то вроде Бласа. Они стали более популярными в последнее время, я думаю, из-за больших достижений графических карт по сравнению с процессорами, все еще очень специализированная область, хотя с большой кривой обучения IMHO как OpenMP, который вы можете просто вставить несколько производных препроцессора на ваших петлях, или что-то вроде новых параллельных коллекций java8. Во всяком случае, это мои 2 цента.