|
|
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
WarstoneНу выполнение агрегатов точно быстрее на GPU. Равно как и WINDOW функций. А вот сортировка - да... тут сложно. Хотя... Надо подумать... Но я все-равно не верю, что нельзя на GPU переложить часть работы, когда транзакции удовлетворены, видимость данных подтверждена (кстати, не полностью, и если это MVCC) и можно отправлять задачу на GPU. Но вообще... Ждем Inter Fermi или как оно там... Математический сопроцессор с 96 ядрами уровня П3. Говорили будет в этом году. Мнямка! Оконные функции обычно вычисляются над результирующими данными, и их результат выводиться клиенту, т.е. там мало данных и GPU не требуется. С сортировкой уже все самое сложное сделал Duane Merrill. На равных по цене CPU и GPU скорость на GPU в 5 раз больше. Кстати сортировка настолько медленная операция, что вклад PCI-E в общее время невелик. В любом случае получается что 1 GPU, заменит минимум 5 CPU той же цены для задач сортировки и агрегирования. А если беспокоитесь о низкой скорости дисковой подсистемы то ставьте 1 сокетный сервер под DWH и аналитику :) Что, нужен 4-8 сокетный? Здесь на порядок дешевле 1 сервер с 1 CPU и 1 GPU. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.12.2011, 17:25 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
Edd.DragonТочно так же и по поводу перебора паролей (гораздо более GPU-шной задачи) цифры маркетологи хорошенько завышают. Это я все к тому - что официальные материалы говорят одно, а потом сообщество под стимулом спортивного интереса тратит время и достигает другого. Вот в конкретном примере про перебор паролей не соглашусь. Это идеальная задача под GPU. Сообщество которое это опровергает - крайне неквалифицированное. Эта задача даже не упирается в доступ к памяти, даже к разделяемой памяти. Т.е. работает с максимальным ускорением. Основное время тратиться на вычисление хэша пароля со сложностью 1000-100000. Т.е. одна и таже функция, выполняется над данными одного и того же регистра 100000 раз и так каждое ядро и каждый поток. Здесь и проявляются все заявленные 500 - 2000 GFlops. Но конечно если представителем сообщества будет Bazist, то он реализует это медленнее чем на калькуляторе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.12.2011, 17:38 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
Это идеальная задача, Идеального ничего не бывает. Но кто-то спорил, что это отличная задача для GPU? По поводу Базиста, ну вот есть: - crark http://www.crark.net - Advanced Archive Password Recovery http://www.elcomsoft.com/archpr.html - Elcomsoft Wireless Security Auditor http://www.elcomsoft.com/ewsa.html - Advanced PDF Password Recovery http://www.elcomsoft.com/apdfpr.html которые протестированы в http://www.golubev.com/about_cpu_and_gpu_ru.htm (давненько уже). Можно считать их базистами и бесконечно ждать идеального разработчика. Но так ускорения точно не получится. Итог того тестирования: - круто, действительно ускоряемся (в прочем никто не сомневался). Карта не самая быстрая, хотя на тот момент - нормальная. Прирост разный. До 30х. Допустим, на более быстрой карте того времени был бы 50х. Но А почему такой маленький прирост?! TACC1441 обещает 60-ти кратный прирост. EDPR декларирует 100x и 200x. Почему же тут получилось «только» 30? Вот об этом я говорю. Большинство людей прочли где-нибудь новости о 100-200х, запомнили и утвердились в мысли. Излишняя уверенность в большом результате - это тоже одна из причин последующих провалов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.12.2011, 17:54 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovWarstoneНу выполнение агрегатов точно быстрее на GPU. Да неужели? А исходные данные для этих агрегатов ты собираешься из ГСЧ брать или всё же c диска? Как на твоём GPU вычислить это: Код: sql 1. 2. С кеша. Причем сначала - кеш а GPU, потом в оперативки, ну а потом уже - на диске. Мы-же прекрасно понимаем, что для OLTP (а для OLAP рассматривать GPU вообще не имеет смысла, там действительно IO bound) 90% данных закешировано. По поводу вопроса: Ну для начала WHERE вычисляется моментально, это, надеюсь, понятно (или вам по шагам?) Частичные суммы вычисляются по аналогии с суммированием большого кол-ва чисел. маны о том, как это делать на GPU есть у nVidia. Я могу ошибаться, но там говорилось о 22х кратном приросте что-ли. avg - это sum/count... Проблема с group by и последующий order by, так как сортировка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2012, 00:37 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
Warstoneдля начала WHERE вычисляется моментально, это, надеюсь, понятно (или вам по шагам?) По шагам, по шагам. Причём начиная от данных, лежащих в блоке данных. Пусть даже в кэше (хотя мы все знаем, что как раз в OLTP таких запросов в принципе нет). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2012, 02:19 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov По шагам, по шагам. Причём начиная от данных, лежащих в блоке данных. Пусть даже в кэше +1 11842534 авторИ ИМХО качественно его кормить, и паралельно рекордно доить у вас получиться на достаточно узком круге задач. Хотелось бы формализовать круг задач, где и когда получится одновременно быстро кормить и рекордно доить Ведь рот и вымя там в одном месте, на шине. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 15:00 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
Ну идея запускать некоторые части CУБД на специализированных процессорах не нова. DB2 for zOS и zIIP. http://en.wikipedia.org/wiki/ZIIP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2012, 13:25 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
xz321Ну идея запускать некоторые части CУБД на специализированных процессорах не нова. DB2 for zOS и zIIP. http://en.wikipedia.org/wiki/ZIIP Мы пробовали GPU на двух задачах (одна из них СУБД). Нигде не получили реально заметного прироста (данные нужно подготовить, а потом их разобрать). На тех видеоплатах которые мы использовали реально быстрой оперативки было мало для больших блоков данных. Возможно мы что то не так делали. Представляется что имеет смысл использовать аппаратный ускоритель для работы с большими массивами данных, но специализированный именно для задач СУБД и тесно интегрированный в ядро СУБД. Например на FPGA. Но он конечно уже не будет таким дешевым как видеокарты. Может быть когда ни будь попробуем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2012, 17:38 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
Ну вот Larrabbe возможно станет чем-то средним и вполне применимым. Посмотрим )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2012, 18:07 |
|
||
|
СУБД, использующая вычисления на GPU.
|
|||
|---|---|---|---|
|
#18+
serg99Мы пробовали GPU на двух задачах (одна из них СУБД) Можно хоть немного деталей: что за СУБД, если не секрет? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2012, 20:08 |
|
||
|
|
start [/forum/topic.php?fid=35&gotonew=1&tid=1552603]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 10ms |
| total: | 149ms |
| 0 / 0 |
