Комментарии 37
Радует, что есть такое.
eclipse на нем как-то можно запустить?
эм… Я видимо чего-не понимаю. Но Java и без сборщика мусора?
Задача, которую я бы хотел перенести на GPU — работа с базами данных. Особенно сложные выборки ох как здорово бы распараллеливались.
Не очень понятно, причём здесь Java (т.к. большинство БД всё-таки написаны на других ЯП).
Насколько я понимаю работу БД, запрос тяжело распараллеливается, потому как представляет из себя набор последовательно применённых ограничений (как распараллелить, например, name = 'Ivan' and age > 20 and age < 40 ?)
Насколько я понимаю работу БД, запрос тяжело распараллеливается, потому как представляет из себя набор последовательно применённых ограничений (как распараллелить, например, name = 'Ivan' and age > 20 and age < 40 ?)
Работа с БД вообще зачастую в диск упирается.
Java тут и впрямь не при чём. Но запрос, который вы привели отлично выполняется параллельно, сначала ищем из всего набора данных, те, которые удовлетворяют условию age > 20, потом в найденных ищем age < 40.
Я как-то наткнулся на исследования по ускорению sqlite с помощью GPU. Минимальное ускорение на тестовых запросах было 20х, среднее 35х. pbbakkum.com/db/
Я как-то наткнулся на исследования по ускорению sqlite с помощью GPU. Минимальное ускорение на тестовых запросах было 20х, среднее 35х. pbbakkum.com/db/
Может быть я чего-то не понимаю, но где здесь параллелизм? Мы выполняем операции последовательно: сначала первое ограничение age > 20, потом второе age < 40.
К примеру, есть 100 потоков и миллион строк в таблице, первый поток будет проверять наше условие в первой строке, потом в 101-ой, и т.д. второй поток во второй, 102-й и т.д. Таким образом вместо миллиона сравнений в одном потоке мы то же число сравнений выполнили в 100 раз быстрее в 100 потоках, при условии что они потоки выполняются параллельно. Вторая операция основывается на результатах первой и выполняется так же параллельно.
Понятно, это тогда параллелизация одной операции, а не всего запроса.
А как по вашему это работает в базе данных? Сначала запрос разбивается на операции, они выполняются в нужном порядке. Если каждую из операций выполнить быстрее запрос разве не выиграет? :)
Уже говорили выше, в данном случае узким местом является жесткий диск, а не процессор.
В каком «данном»? Правильно писать что жесткий диск может быть узким местом, но не обязательно. Может быть это быстрый массив твердотельных-дисков, может быть in-memory база данных, а может быть просто очень сложный запрос на маленькой базе. В любом случае как и с запуском java на GPU будут случаи когда выполнение сравнений на GPU значительно ускорит работу базы данных, и с другой стороны, буду случаи когда GPU только ухудшит производительность.
Если говорить про реляционные базы, то там планировщик обработки запроса бьет запрос на набор шагов, которые чаще всего, могут быть выполнены только последовательно (собственно задача планировщика — как раз и выбрать последовательность шагов). Сами отдельные шаги тоже особо не распараллелишь (как распараллелить поиск по индексу или балансировку дерева?). Так что не очень ясно про какой способ «выполнить операции быстрее» вы подразумеваете.
Однако, использование индексов отбрасывает необходимость делать миллион сравнений.
Индексы разве мешают распараллелить операцию сравнения или поиска? Или в чем это существенно меняет описываемую проблему. Да, с индексами будет быстро, но можно же еще быстрее!
Индексы не мешают, индексы сводят миллион сравнений к двадцати — а тут накладные расходы на распараллеливание все и накроют мешком.
То, что вы описываете — это операция типа «full table scan», которая обычно упирается в диск, а значит описанный способ «распараллеливания» только снизит скорость обработки. В нормальной же ситуации поиск идет с помощью индексов и это очень проблематично распараллелить.
Можете привести пример хотя бы одной адекватной ситуации, где распараллеливание на GPU работы базы данных могло бы помочь?
НЛО прилетело и опубликовало эту надпись здесь
> Компилятор опубликован под свободной лицензией GNU GPLv3
Цитата из README в репозитории (по самой первой ссылке в посте, похоже пару дней назад поменялась):
> Rootbeer is licensed under the MIT license.
Цитата из README в репозитории (по самой первой ссылке в посте, похоже пару дней назад поменялась):
> Rootbeer is licensed under the MIT license.
Упс, появился второй способ запускать джаву на GPU.
Коллеги, есть хорошо отлаженная и зарекомендовавшая себя технология Azul.
Во первых она так-же как и CUDA распараллеливает задачу на большое количество ядер (Вплоть до 864 на одну вычислительную коробочку) И вдобавок к этому имеет реализацию сборщика мусора, работающего БЕЗ пауз. Механизм «Запасной памяти» если программа страдает утечками, чтобы не выпадать по OutOfMemory.
Кроме всего прочего вы получаете профилировку программ в промышленной среде, без потери производительности.
http://www.azulsystems.com/products/vega/overview
Есть софтовая реализация этого же продукта:
http://www.azulsystems.com/products/zing/whatisit
Во первых она так-же как и CUDA распараллеливает задачу на большое количество ядер (Вплоть до 864 на одну вычислительную коробочку) И вдобавок к этому имеет реализацию сборщика мусора, работающего БЕЗ пауз. Механизм «Запасной памяти» если программа страдает утечками, чтобы не выпадать по OutOfMemory.
Кроме всего прочего вы получаете профилировку программ в промышленной среде, без потери производительности.
http://www.azulsystems.com/products/vega/overview
Есть софтовая реализация этого же продукта:
http://www.azulsystems.com/products/zing/whatisit
Что-то оно нифига не open source.
ну имеется у меня хорошая видюха и задача по перемалыванию данных,
написал прогу на java
Rootbeer:
+ использует CUDA, соответвенно для сугубо вычислительных задач можно получиться хорошее ускорение
— ну да, нельзя всю мощь java использовать, но нам же только посчитать для примера хеш или еще чего, так что объектной модели серьезной там и не пахнет
Aluz:
+ для промышленных систем возможно и применима
— купить железку на 864 ядра для запуска ява машины, но допустим мы просто заюзаем софтварную версию, но тогда упираемся в количество ядер нашего проца и приплыли…
— купить саму jvm, которая тоже не совсем копейки стоит
Так что ваше сравнение, мягко говоря, не в тему.
P.S. хватит уже пиарить Aluz, я понимаю что вам она может нравиться, но так откровенно пытаться пиарить ее не нужно, лучше расскажите плюсы на реальных задачах + корректные тесты приведите, некоторые тесты из разряда — попытался запустить, не сильно понравилось скорость или сырой g1, зато вот в azul мы настроили то-то и то-то.
написал прогу на java
Rootbeer:
+ использует CUDA, соответвенно для сугубо вычислительных задач можно получиться хорошее ускорение
— ну да, нельзя всю мощь java использовать, но нам же только посчитать для примера хеш или еще чего, так что объектной модели серьезной там и не пахнет
Aluz:
+ для промышленных систем возможно и применима
— купить железку на 864 ядра для запуска ява машины, но допустим мы просто заюзаем софтварную версию, но тогда упираемся в количество ядер нашего проца и приплыли…
— купить саму jvm, которая тоже не совсем копейки стоит
Так что ваше сравнение, мягко говоря, не в тему.
P.S. хватит уже пиарить Aluz, я понимаю что вам она может нравиться, но так откровенно пытаться пиарить ее не нужно, лучше расскажите плюсы на реальных задачах + корректные тесты приведите, некоторые тесты из разряда — попытался запустить, не сильно понравилось скорость или сырой g1, зато вот в azul мы настроили то-то и то-то.
Ждем сравнения стоимости 864-ядерного Azul box с топовой видеокартой.
> Во первых она так-же как и CUDA распараллеливает задачу на большое количество ядер
Ну тогда у меня HotSpot на моем ноуте сам распаралеливает задачу на 4 ядра.
Azul распараллеливает задачу ровно настолько насколько она уже распараллелена девелопером.
Ну тогда у меня HotSpot на моем ноуте сам распаралеливает задачу на 4 ядра.
Azul распараллеливает задачу ровно настолько насколько она уже распараллелена девелопером.
объясните чайнику: современные GPU таки являются полноценными процессорами? Или все же основная логика остается на CPU, а графика только числа молотить умеет?
спасибо, посмотрю! в своей работе использовал jCuda
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Запускаем Java-программы на GPU