Запускаем Java-программы на GPU

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

    Компилятор опубликован под лицензией MIT, он прошёл тщательное тестирование и вполне пригоден для использования. По словам автора, это самый продвинутый транслятор байткода Java на платформу CUDA. Судя по всему, OpenCL тоже поддерживается.

    Автор программы — преподаватель Сиракузского университета Фил Пратт-Желига (Phil Pratt-Szeliga).

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

    Если в Java-программе есть параллелизм, то Rootbeer обнаружит его автоматически. В этом случае на специфических задачах прибавка производительности может составить десятки раз. Например, во время тестирования умножение плотных матриц 4096х4096 на Java с Rootbeer ускорилось в 67 раз, преобразование Фурье (не FFT) — в 54 раза.

    Rootbeer использует инструмент для статического анализа и преобразования Java-байткода Soot.

    Список неподдерживаемых функций Java в компиляторе: сборщик мусора, нативные методы, отражения (рефлексия), динамический вызов методов.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 37

      0
      Радует, что есть такое.
        +8
        eclipse на нем как-то можно запустить?
          +40
          Тоже надеетесь, что перестанет тормозить? :)
          +4
          эм… Я видимо чего-не понимаю. Но Java и без сборщика мусора?
            0
            сборщик мусора будет продолжать работать на CPU, судя по всему.
              +1
              Ну как, java card — это же тоже java? Да и вообще, был тут один товарищ, который сборщик мусора выпилил.
              –4
              Задача, которую я бы хотел перенести на GPU — работа с базами данных. Особенно сложные выборки ох как здорово бы распараллеливались.
                +2
                Не очень понятно, причём здесь Java (т.к. большинство БД всё-таки написаны на других ЯП).
                Насколько я понимаю работу БД, запрос тяжело распараллеливается, потому как представляет из себя набор последовательно применённых ограничений (как распараллелить, например, name = 'Ivan' and age > 20 and age < 40 ?)
                  +7
                  Работа с БД вообще зачастую в диск упирается.
                    –3
                    Java тут и впрямь не при чём. Но запрос, который вы привели отлично выполняется параллельно, сначала ищем из всего набора данных, те, которые удовлетворяют условию age > 20, потом в найденных ищем age < 40.

                    Я как-то наткнулся на исследования по ускорению sqlite с помощью GPU. Минимальное ускорение на тестовых запросах было 20х, среднее 35х. pbbakkum.com/db/
                      +2
                      Может быть я чего-то не понимаю, но где здесь параллелизм? Мы выполняем операции последовательно: сначала первое ограничение age > 20, потом второе age < 40.
                        0
                        К примеру, есть 100 потоков и миллион строк в таблице, первый поток будет проверять наше условие в первой строке, потом в 101-ой, и т.д. второй поток во второй, 102-й и т.д. Таким образом вместо миллиона сравнений в одном потоке мы то же число сравнений выполнили в 100 раз быстрее в 100 потоках, при условии что они потоки выполняются параллельно. Вторая операция основывается на результатах первой и выполняется так же параллельно.
                          0
                          Понятно, это тогда параллелизация одной операции, а не всего запроса.
                            0
                            А как по вашему это работает в базе данных? Сначала запрос разбивается на операции, они выполняются в нужном порядке. Если каждую из операций выполнить быстрее запрос разве не выиграет? :)
                              0
                              Уже говорили выше, в данном случае узким местом является жесткий диск, а не процессор.
                                0
                                В каком «данном»? Правильно писать что жесткий диск может быть узким местом, но не обязательно. Может быть это быстрый массив твердотельных-дисков, может быть in-memory база данных, а может быть просто очень сложный запрос на маленькой базе. В любом случае как и с запуском java на GPU будут случаи когда выполнение сравнений на GPU значительно ускорит работу базы данных, и с другой стороны, буду случаи когда GPU только ухудшит производительность.
                                0
                                Если говорить про реляционные базы, то там планировщик обработки запроса бьет запрос на набор шагов, которые чаще всего, могут быть выполнены только последовательно (собственно задача планировщика — как раз и выбрать последовательность шагов). Сами отдельные шаги тоже особо не распараллелишь (как распараллелить поиск по индексу или балансировку дерева?). Так что не очень ясно про какой способ «выполнить операции быстрее» вы подразумеваете.
                              0
                              Однако, использование индексов отбрасывает необходимость делать миллион сравнений.
                                0
                                Индексы разве мешают распараллелить операцию сравнения или поиска? Или в чем это существенно меняет описываемую проблему. Да, с индексами будет быстро, но можно же еще быстрее!
                                  0
                                  Индексы не мешают, индексы сводят миллион сравнений к двадцати — а тут накладные расходы на распараллеливание все и накроют мешком.
                                    0
                                    Ок, у вас 50 полей, по ним идет выборка. Вы будете делать 50 индексов?
                                      0
                                      1. Это, несомненно, очень рядовая ситуация. Так постоянно происходит прям везде.

                                      2. Зависит от количества типов выборок, числа записей в таблице, динамики чтения-записи…
                                        0
                                        Для поиска, да. Для выборки или MapReduce что будем делать? О чем вобще спор, что вы пробуете доказать? :)
                                          0
                                          Да всего лишь что от тотального распараллеливания вычисления БД врядли что-то заметное выиграет — кроме достаточно специфических ситуаций.
                                +1
                                То, что вы описываете — это операция типа «full table scan», которая обычно упирается в диск, а значит описанный способ «распараллеливания» только снизит скорость обработки. В нормальной же ситуации поиск идет с помощью индексов и это очень проблематично распараллелить.
                          0
                          Можете привести пример хотя бы одной адекватной ситуации, где распараллеливание на GPU работы базы данных могло бы помочь?
                            +1
                            Если у вас есть какие-то операции над данными, которые упираются не в диск, а в CPU, то вам стоит глянуть в сторону MapReduce, например.
                            0
                            > Компилятор опубликован под свободной лицензией GNU GPLv3

                            Цитата из README в репозитории (по самой первой ссылке в посте, похоже пару дней назад поменялась):

                            > Rootbeer is licensed under the MIT license.
                              +1
                              Упс, появился второй способ запускать джаву на GPU.
                                0
                                Коллеги, есть хорошо отлаженная и зарекомендовавшая себя технология Azul.
                                Во первых она так-же как и CUDA распараллеливает задачу на большое количество ядер (Вплоть до 864 на одну вычислительную коробочку) И вдобавок к этому имеет реализацию сборщика мусора, работающего БЕЗ пауз. Механизм «Запасной памяти» если программа страдает утечками, чтобы не выпадать по OutOfMemory.
                                Кроме всего прочего вы получаете профилировку программ в промышленной среде, без потери производительности.
                                http://www.azulsystems.com/products/vega/overview

                                Есть софтовая реализация этого же продукта:
                                http://www.azulsystems.com/products/zing/whatisit
                                  +1
                                  Что-то оно нифига не open source.
                                    0
                                    ну имеется у меня хорошая видюха и задача по перемалыванию данных,
                                    написал прогу на java

                                    Rootbeer:
                                    + использует CUDA, соответвенно для сугубо вычислительных задач можно получиться хорошее ускорение
                                    — ну да, нельзя всю мощь java использовать, но нам же только посчитать для примера хеш или еще чего, так что объектной модели серьезной там и не пахнет

                                    Aluz:
                                    + для промышленных систем возможно и применима
                                    — купить железку на 864 ядра для запуска ява машины, но допустим мы просто заюзаем софтварную версию, но тогда упираемся в количество ядер нашего проца и приплыли…
                                    — купить саму jvm, которая тоже не совсем копейки стоит

                                    Так что ваше сравнение, мягко говоря, не в тему.

                                    P.S. хватит уже пиарить Aluz, я понимаю что вам она может нравиться, но так откровенно пытаться пиарить ее не нужно, лучше расскажите плюсы на реальных задачах + корректные тесты приведите, некоторые тесты из разряда — попытался запустить, не сильно понравилось скорость или сырой g1, зато вот в azul мы настроили то-то и то-то.
                                      +1
                                      Ждем сравнения стоимости 864-ядерного Azul box с топовой видеокартой.
                                        +1
                                        > Во первых она так-же как и CUDA распараллеливает задачу на большое количество ядер
                                        Ну тогда у меня HotSpot на моем ноуте сам распаралеливает задачу на 4 ядра.
                                        Azul распараллеливает задачу ровно настолько насколько она уже распараллелена девелопером.
                                        +3
                                        объясните чайнику: современные GPU таки являются полноценными процессорами? Или все же основная логика остается на CPU, а графика только числа молотить умеет?
                                          0
                                          По сути да, почти универсальные. Но с крайне скудным набором команд если сравнивать с x86, и массой ограничений по объему доступной памяти на ядро и методов работы с ней.
                                          Если нужно что-то более удобное, то на подходе MIC от Intel.
                                          0
                                          спасибо, посмотрю! в своей работе использовал jCuda

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое