Комментарии 22
Очень полезная информация.
Оффтоп: мне вот тут подумалось:
— Вычисления на GPU правильно применять для задач по параллельной обработке более-менее объёмных данных.
— Точнее всего под это подходит СУБД.
— А вот круто было бы иметь СУБД, которая работает на GPU, в следствие чего её производительность сильно выше других СУБД на обычных CPU. Такая СУБД имела бы оромный успех у highload проектов, ИМХО.
— А если бы она ещё бы легко масштабировалась добавлением видеокарт и машин, было бы вообще супер!
Оффтоп: мне вот тут подумалось:
— Вычисления на GPU правильно применять для задач по параллельной обработке более-менее объёмных данных.
— Точнее всего под это подходит СУБД.
— А вот круто было бы иметь СУБД, которая работает на GPU, в следствие чего её производительность сильно выше других СУБД на обычных CPU. Такая СУБД имела бы оромный успех у highload проектов, ИМХО.
— А если бы она ещё бы легко масштабировалась добавлением видеокарт и машин, было бы вообще супер!
Идея хорошая, но есть ряд узких моментов, таких как копирование данных с хоста на девайс и обратно, это может стать критичным в СУБД. Использование GPU подразумевает большой объем вычислений, проводимых над данными, поэтому СУБД для GPU должна быть весьма специализированной.
> копирование данных с хоста на девайс и обратно, это может стать критичным в СУБД
Кстати, а во сколько раз копирование с хоста на девайс медленнее копирования из памяти в память внутри хоста?
> поэтому СУБД для GPU должна быть весьма специализированной.
Я тут подумал, что логичней сделать какой-нить движок таблик к мусклу/постресу, которые подразумевает хранение таблицы в памяти видеокарты. Тогда можно было бы засунуть туда пару таблиц даже не особо маленьких и выполнять выборку из них со сложными условиями и сортировками. И лишь изредка синхронизировать таблицы с хостом, да и то только если они меняются.
Я вот сейчас прикинул, найдётся немного задач, которые лучше решались бы таким вот движком таблиц. Однако если бы я на этапе архитектуры имел в виду такой движок, то этих задач было бы на много больше.
Но в целом действительно выглядит очень уж узкоспециализированно.
Кстати, а во сколько раз копирование с хоста на девайс медленнее копирования из памяти в память внутри хоста?
> поэтому СУБД для GPU должна быть весьма специализированной.
Я тут подумал, что логичней сделать какой-нить движок таблик к мусклу/постресу, которые подразумевает хранение таблицы в памяти видеокарты. Тогда можно было бы засунуть туда пару таблиц даже не особо маленьких и выполнять выборку из них со сложными условиями и сортировками. И лишь изредка синхронизировать таблицы с хостом, да и то только если они меняются.
Я вот сейчас прикинул, найдётся немного задач, которые лучше решались бы таким вот движком таблиц. Однако если бы я на этапе архитектуры имел в виду такой движок, то этих задач было бы на много больше.
Но в целом действительно выглядит очень уж узкоспециализированно.
>Кстати, а во сколько раз копирование с хоста на девайс медленнее копирования из памяти в память внутри хоста?
Страно, что сам этим вопросом не задавался. Протестирую — отпишусь.
По-второму пункту: количество операций с таблицами должно быть весьма внушительно, чтобы компенсировать издержки синхронизации девайса и хоста. Ждем архитектуру без хоста, которую в Intel так боятся :).
Страно, что сам этим вопросом не задавался. Протестирую — отпишусь.
По-второму пункту: количество операций с таблицами должно быть весьма внушительно, чтобы компенсировать издержки синхронизации девайса и хоста. Ждем архитектуру без хоста, которую в Intel так боятся :).
> количество операций с таблицами должно быть весьма внушительно,
> чтобы компенсировать издержки синхронизации девайса и хоста.
Ну это в любом случае подходит для задач, когда нам не надо иметь полностью актуальную таблицу на хосте. Либо, если изменения таблицы достаточно дёшевы, их можно выполнять параллельно на хосте и девайсе. Надо только позаботиться, чтобы они выполнялись абсолютно одинаково.
> чтобы компенсировать издержки синхронизации девайса и хоста.
Ну это в любом случае подходит для задач, когда нам не надо иметь полностью актуальную таблицу на хосте. Либо, если изменения таблицы достаточно дёшевы, их можно выполнять параллельно на хосте и девайсе. Надо только позаботиться, чтобы они выполнялись абсолютно одинаково.
$ ./bandwidthTest
Running on…
device 0:GeForce 9600 GT
Quick Mode
Host to Device Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 2274.1
Quick Mode
Device to Host Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 2103.7
Quick Mode
Device to Device Bandwidth
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 29141.2
Как видим, разница почти в 15 раз
Running on…
device 0:GeForce 9600 GT
Quick Mode
Host to Device Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 2274.1
Quick Mode
Device to Host Bandwidth for Pageable memory
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 2103.7
Quick Mode
Device to Device Bandwidth
.
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 29141.2
Как видим, разница почти в 15 раз
Всегда думал, что СУБД почти всегда упираются в IO, а не в CPU.
Я как раз разрабатываю такую СУБД :) Не совсем СУБД конечно, моя разработка основана на sqlite.
В рамках работы над своей диссертацией. Самому интересно узнать чем это все кончится, планирую чуть позже открыть исходники. Приятно слышать, что у кого то схожие мысли.
В рамках работы над своей диссертацией. Самому интересно узнать чем это все кончится, планирую чуть позже открыть исходники. Приятно слышать, что у кого то схожие мысли.
У самого есть пара проектов, которые sqlite используют. Очень интересно что у вас получится.
А это будет кроссплатформенно? И под какой лицензией собираетесь выкладывать, если собираетесь?
Новости есть?
Спасибо за статьи :)
Интересно, кто-нибудь из разработчиков физических движков (в частности ODE) уже начал примеряться к CUDA? Было бы очень полезно и интересно, насколько выросла бы производительность.
С одной стороны, задачи твердотельного моделирования как нельзя лучше подходят для SIMD (по сути сплошные матрицы). С другой — там много мест где принимаются решения на базе условий, так что хз, можно ли разложить это в поток.
Интересно, кто-нибудь из разработчиков физических движков (в частности ODE) уже начал примеряться к CUDA? Было бы очень полезно и интересно, насколько выросла бы производительность.
С одной стороны, задачи твердотельного моделирования как нельзя лучше подходят для SIMD (по сути сплошные матрицы). С другой — там много мест где принимаются решения на базе условий, так что хз, можно ли разложить это в поток.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CUDA: Работа с памятью. Часть II.