Как стать автором
Обновить

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

Очень полезная информация.

Оффтоп: мне вот тут подумалось:
— Вычисления на GPU правильно применять для задач по параллельной обработке более-менее объёмных данных.
— Точнее всего под это подходит СУБД.
— А вот круто было бы иметь СУБД, которая работает на GPU, в следствие чего её производительность сильно выше других СУБД на обычных CPU. Такая СУБД имела бы оромный успех у highload проектов, ИМХО.
— А если бы она ещё бы легко масштабировалась добавлением видеокарт и машин, было бы вообще супер!
Идея хорошая, но есть ряд узких моментов, таких как копирование данных с хоста на девайс и обратно, это может стать критичным в СУБД. Использование GPU подразумевает большой объем вычислений, проводимых над данными, поэтому СУБД для GPU должна быть весьма специализированной.
> копирование данных с хоста на девайс и обратно, это может стать критичным в СУБД
Кстати, а во сколько раз копирование с хоста на девайс медленнее копирования из памяти в память внутри хоста?

> поэтому СУБД для GPU должна быть весьма специализированной.
Я тут подумал, что логичней сделать какой-нить движок таблик к мусклу/постресу, которые подразумевает хранение таблицы в памяти видеокарты. Тогда можно было бы засунуть туда пару таблиц даже не особо маленьких и выполнять выборку из них со сложными условиями и сортировками. И лишь изредка синхронизировать таблицы с хостом, да и то только если они меняются.

Я вот сейчас прикинул, найдётся немного задач, которые лучше решались бы таким вот движком таблиц. Однако если бы я на этапе архитектуры имел в виду такой движок, то этих задач было бы на много больше.

Но в целом действительно выглядит очень уж узкоспециализированно.
>Кстати, а во сколько раз копирование с хоста на девайс медленнее копирования из памяти в память внутри хоста?
Страно, что сам этим вопросом не задавался. Протестирую — отпишусь.

По-второму пункту: количество операций с таблицами должно быть весьма внушительно, чтобы компенсировать издержки синхронизации девайса и хоста. Ждем архитектуру без хоста, которую в 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 раз
Всегда думал, что СУБД почти всегда упираются в IO, а не в CPU.
Не редко возникают задачи, где СУБД упирается в CPU как раз.
Как думаете, почему на серверах БД оперативки 16-32гб?)
В CPU…
Чтобы данные таблиц с диска кешировать и буфер разобранных запросов держать. CPU почти не у дел…
Я как раз разрабатываю такую СУБД :) Не совсем СУБД конечно, моя разработка основана на sqlite.
В рамках работы над своей диссертацией. Самому интересно узнать чем это все кончится, планирую чуть позже открыть исходники. Приятно слышать, что у кого то схожие мысли.
У самого есть пара проектов, которые sqlite используют. Очень интересно что у вас получится.
Я постараюсь написать об этом в своем блоге, как только получу более менее работающую бету. Сейчас все разрознено и стоят немного другие цели.
А это будет кроссплатформенно? И под какой лицензией собираетесь выкладывать, если собираетесь?
Думаю да. Лицензия — да такая же что и у sqlite наверное, т.е. никаких ограничений.
Шикарно. Хочу быть как минимум в курсе о Вашей разработке. Вы где-нибудь о ней пишете?
Нет, пока не пишу. Много времени отнимает основная работа. Но как только будет то, что можно потестировать, я напишу администратору этого раздела, так что, думаю, вы не пропустите.
Новости есть?
Спасибо за статьи :)

Интересно, кто-нибудь из разработчиков физических движков (в частности ODE) уже начал примеряться к CUDA? Было бы очень полезно и интересно, насколько выросла бы производительность.

С одной стороны, задачи твердотельного моделирования как нельзя лучше подходят для SIMD (по сути сплошные матрицы). С другой — там много мест где принимаются решения на базе условий, так что хз, можно ли разложить это в поток.
У nVidia есть физический движок PhysX, которые базируется на CUDA.
По поводу использования CUDA в задачах моделирования — примеры можно посмотреть здесь
Я знаю про physX, но меня интересует именно ODE. Возможно конечно они сделают порт для физикса.
Если физический движок изначально писался под CPU, то сделать версию под GPU, все равно, что с нуля начать проект, разве что интерфейсную часть оставить неизменной для пользователей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории