Comments 23
Только недавно задумывался как было бы хорошо использовать GPU в процессе рендеринга Sweet Home 3D. Интересно, как долго ждать внедрения такой функции в Sweet Home 3D.
Рендеринг тут никаким боком не в тему.
Объясните
О, даже как, ваш вопрос уже задавали на официальном форуме Sweet Home. Один из интересных ответов в том, что на GPU вы сможете получить картинку худшего качества, нежели чем на CPU. Поэтому совет — наращивать ядра и архитектуру именно процессора, а не графической карты.
CUDA — это платформа для использования GPU не по их первоначальному назначению: для вычислений. К рендерингу имеет отношение только потому как используются те же мощности, хоть и для несколько других задач. Для Sweet Home 3D нужен именно рендеринг и делать его через CUDA, как по мне, изврат. Для этого есть OpenGL.
jcuda есть же уже давно, уже 2 года как на ней пишу дисер!
бла-бла-бла смотрите какие мы круты бла-бла-бла
code.google.com/p/aparapi/
Спонируется amd
Компиляция java кода в нативный opencl kernel, дальше уже без разницы это nvidia, amd или вообще arm (вроде как уже запускали). В данный момент работают над поддержкой HSA, а значит открываются еще более широкие возможности по использованию arm soc и dsp. Есть поддержка lambda и java8.
rbcompiler.com/
Rootbeer
Те же яйца aparapi, только в профиль. Правда компиляция в код для opencl и cuda, местами смотрится лучше, местами хуже
openjdk.java.net/projects/graal/
Проект graal
Пишем jit компилер для java bytecode на самой java. В качестве бекендов в разработке компиляция в ptx, который уже потом уйдет в cuda.
В чем новость? в том что IBM сумели заюзать из java cuda и потаются на пару продавить очередной vendor lock-in?
Спасибо, не надо.
code.google.com/p/aparapi/
Спонируется amd
Компиляция java кода в нативный opencl kernel, дальше уже без разницы это nvidia, amd или вообще arm (вроде как уже запускали). В данный момент работают над поддержкой HSA, а значит открываются еще более широкие возможности по использованию arm soc и dsp. Есть поддержка lambda и java8.
rbcompiler.com/
Rootbeer
Те же яйца aparapi, только в профиль. Правда компиляция в код для opencl и cuda, местами смотрится лучше, местами хуже
openjdk.java.net/projects/graal/
Проект graal
Пишем jit компилер для java bytecode на самой java. В качестве бекендов в разработке компиляция в ptx, который уже потом уйдет в cuda.
В чем новость? в том что IBM сумели заюзать из java cuda и потаются на пару продавить очередной vendor lock-in?
Спасибо, не надо.
Строго говоря, в CUDA может быть два подхода.
Вариант 1: надо сделать что-то низкоуровневрое, отточенное по производительности, идеально использующее девайс. Решение: используем CUDA C.
Вариант 2: надо сделать что-то обобщенное, посчитать Блэка-Шоулза или что-нть аналогичное. Решение: используем Thrust или еще какую-нть библиотеку. Такие библиотеки как раз и нужно иметь в разных языках.
Что касается транскомпиляции Java-->PTX, это имхо плохая идея. Уже пробовали и не раз, тот же Aparapi, GPU.NET (F#), и так далее. Ничем хорошим это не закончилось.
Вариант 1: надо сделать что-то низкоуровневрое, отточенное по производительности, идеально использующее девайс. Решение: используем CUDA C.
Вариант 2: надо сделать что-то обобщенное, посчитать Блэка-Шоулза или что-нть аналогичное. Решение: используем Thrust или еще какую-нть библиотеку. Такие библиотеки как раз и нужно иметь в разных языках.
Что касается транскомпиляции Java-->PTX, это имхо плохая идея. Уже пробовали и не раз, тот же Aparapi, GPU.NET (F#), и так далее. Ничем хорошим это не закончилось.
А можно ссылки на то, где «Ничем хорошим это не закончилось.»?
Просто aparapi развивается достаточно активно, впиливают новые фичи и тд. Я согласен, что по сравнению с обычным OpenCL это достаточно большой оверхед, но всегда все идет на удешевление разработки, и в данном случае это оказывается оправдано.
Вариант 1: полностью согласен
Вариант 2: если уже готовый алгоритм есть, то можно и через jni дергать, проблема если его нету.
Но как-же вариант 3: хотим проверить теорию о том, что в нашем алгоритме gpu может иметь какой профит?
Нанимать c/c++ кодеров с хорошим знаинем CUDA/OpenCL дорого и к тому же усложняет коммуникацию внутри команды, добавляем сюда, что нанимать мы будем только на пару месяцев и увольняем если GPU нам не подходит. Сомнемаюсь что много найдется желающих рискнуть в этом случае. Библиотеки вроде aparapi позволяют набросать концепт сразу на java.
Просто aparapi развивается достаточно активно, впиливают новые фичи и тд. Я согласен, что по сравнению с обычным OpenCL это достаточно большой оверхед, но всегда все идет на удешевление разработки, и в данном случае это оказывается оправдано.
Вариант 1: полностью согласен
Вариант 2: если уже готовый алгоритм есть, то можно и через jni дергать, проблема если его нету.
Но как-же вариант 3: хотим проверить теорию о том, что в нашем алгоритме gpu может иметь какой профит?
Нанимать c/c++ кодеров с хорошим знаинем CUDA/OpenCL дорого и к тому же усложняет коммуникацию внутри команды, добавляем сюда, что нанимать мы будем только на пару месяцев и увольняем если GPU нам не подходит. Сомнемаюсь что много найдется желающих рискнуть в этом случае. Библиотеки вроде aparapi позволяют набросать концепт сразу на java.
Ну, например Tidepowerd, которые делали GPU.NET, схлопнулись. Aparapi насколько я понимаю ATI передала в open source.
Насчет хороших кодеров это да, есть такая проблема. Хорошие программисты вообще дорогие по определению. Но основная проблема с другими языками что нужно делать фактически репликацию языка. А потом «как, я не могу использовать строки на GPU» и прочие проблемы возникают.
Насчет хороших кодеров это да, есть такая проблема. Хорошие программисты вообще дорогие по определению. Но основная проблема с другими языками что нужно делать фактически репликацию языка. А потом «как, я не могу использовать строки на GPU» и прочие проблемы возникают.
>> ATI
fix
AMD после первых же презентаций по скрещиванию APU и Java обещали открытие библиотеки в опенсорс, правда они больше показывали про HSA единую интеграцию, а aparapi на тот момент поддерживало только OpenCL. Aparapi в данный момент разрабатывают сотрудники AMD JavaLabs, основной разработчик Gary Frost ( a Software Engineer at AMD ). Нету такого, что открыли и забили, тут больше похоже на ситуацию, когда AMD наняла наиболее активных разработчиков открытых драйверов для видеокарт и теперь они уже на fulltime работают над теми же открытыми драйверами.
Поэтому сказать, что aparapi это ошибка и ее забросили я не могу, по моему мнению она более чем жива.
>> «как, я не могу использовать строки на GPU»
в HSA пускай и обрезанная, но поддержка строк имеется, другой вопрос, что не часто нам для вычислений нужны строки
fix
AMD после первых же презентаций по скрещиванию APU и Java обещали открытие библиотеки в опенсорс, правда они больше показывали про HSA единую интеграцию, а aparapi на тот момент поддерживало только OpenCL. Aparapi в данный момент разрабатывают сотрудники AMD JavaLabs, основной разработчик Gary Frost ( a Software Engineer at AMD ). Нету такого, что открыли и забили, тут больше похоже на ситуацию, когда AMD наняла наиболее активных разработчиков открытых драйверов для видеокарт и теперь они уже на fulltime работают над теми же открытыми драйверами.
Поэтому сказать, что aparapi это ошибка и ее забросили я не могу, по моему мнению она более чем жива.
>> «как, я не могу использовать строки на GPU»
в HSA пускай и обрезанная, но поддержка строк имеется, другой вопрос, что не часто нам для вычислений нужны строки
Кстати, забыл, есть еще С++ AMP.
Видели, знаем…
Ограничения: c/c++, windows (intel пиарился, что сделал поверх llvm свою имплементацию стандарта, вот только что-то по этому поводу мало данных)
Сухой итог: привязка к одной платформе и опять же необходимость написания jni обертки для java, а если и алгоритма нету, то пишем все руками + jni.
с++ amp можно лишь рассматривать как частичную более простую замену для CUDA/OpenCL, к java она отношения никакого не имеет.
p.s. если уж припрет сильно что-то посчитать, то с cuda хоть спотовые GPU инстансы у амазона можно взять по дешевке, с amp мы пролетаем, только за полную стоимость windows (дороже на порядок, т.е. в 10 раз).
Ограничения: c/c++, windows (intel пиарился, что сделал поверх llvm свою имплементацию стандарта, вот только что-то по этому поводу мало данных)
Сухой итог: привязка к одной платформе и опять же необходимость написания jni обертки для java, а если и алгоритма нету, то пишем все руками + jni.
с++ amp можно лишь рассматривать как частичную более простую замену для CUDA/OpenCL, к java она отношения никакого не имеет.
p.s. если уж припрет сильно что-то посчитать, то с cuda хоть спотовые GPU инстансы у амазона можно взять по дешевке, с amp мы пролетаем, только за полную стоимость windows (дороже на порядок, т.е. в 10 раз).
со строками, как раз, все просто, это immutable объект, внутри jvm чаще всего преобразуется в char*.
Aparapi жив, насколько жив сам AMD, но немногоие компании могут поддерживать подобные разработки несколько лет, а у Оракла интерес к проекту очень условный
Aparapi жив, насколько жив сам AMD, но немногоие компании могут поддерживать подобные разработки несколько лет, а у Оракла интерес к проекту очень условный
А что, раньше с помощью JNI нельзя было использовать CUDA и OpenCL?
О чём вообще пост? Серверная JVM научится автоматически переносить часть кода на GPU? Если нет — то всё это уже было и уже работало с помощью JNI. Где новости-то?
А где подробности? Что они имели ввиду? Сварганить Java-wrapper, дергающий GPU через JNI? Бессмысленно, т.к. джавовские структуры в памяти абсолютно несовместимы с GPU. Основное время будет тратиться на конвертацию-деконвертацию массивов. Либо жестко ограничиться ByteBuffer-ом. Или это претензия на то, что наш Java-код будет прозрачно компилиться JVM в GPU, и это все будет мирно уживаться с обычным интерпретируемым кодом, плюс автоматически оптимизироваться HotSpot-ом там где можно сгенерить код для GPU? Чтож, коммунизм я вижу более реальным ;)
Я думаю что компилироваться будут либо только специальные классы, либо отдельные мат операции. Не помню название проекта, но я подобное уже видел. Там надо было заимплементить спец интерфейс и в метод передавать флоаты, а все мат операции компилировались в гпу.
По идее можно еще использовать билдер паттерн.
По идее можно еще использовать билдер паттерн.
Все эти проэкты, aparapi, sumatra — это попытки запускать исключительно лямбды на GPU. Там есть 2 большие проблемы — ветвление кода и сборка мусора. Ветвление кода означает, что если N тредов выполняет кодинаковый код надо разными данными вида if (cond) A else B то все N тредов выполняют сперва А, потом B. Если для конкретного N соnd не выполнился, то код А заменяется на nop, в противном случает код B заменяется на nop. Но CPU cycles пропадают все равно. Так что сильно ветвистый код не ускоряется. Проблема со сборщиком мысора вообще имеет единственное решение, конда GC выполняетс на ЦПУ, что возможно в архитектурах типа HSA с единым адресным пространством. Но производительность такого GC будет сильно отставать от мутаторов, в конечном итоге будуь огромные stop the world паузы. Есть вариант пойти путем некоторых real time java кодописателей, когда java код не порождает объектов, но это уже как бы и не java получается.
Sign up to leave a comment.
Ускорение вычислений с помощью GPU, теперь на Java!