Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: СУБД, использующая вычисления на GPU.  [new]
Росгоснанораспилтрест
Member [заблокирован]

Откуда: Главпилорама
Сообщений: 2421
Antony GL
Вопрос.
Какая-нибудь из современных СУБД поддерживает перенос части вычислений с CPU на GPU, если поддерживает, то какими средствами.


Да это полный бред! Узким местом в современных системах хранения данных являются именно эти самые системы хранения, тобишь - дисковые массивы.И 90% производительности зависит от них. Если надо, шоп было мегабыстро, и при этом обслуживало 100500 клиентов - Oracle RAC + SAN за 10005000 бабла, и не иначе.
29 дек 11, 01:35    [11843190]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Росгоснанораспилтрест
Member [заблокирован]

Откуда: Главпилорама
Сообщений: 2421
ДохтаР
А если бизнес будет расти так, что через пару лет решите купить себе блейд шасси
где на серверах нет видеокарт, потому как монитор там нахрен не нужен, терминалкой все управляется.


Тогда, ИМХО, про шиндовс можно забыть. А у ТСа, вроде как, полный и безнадёжный MS.
29 дек 11, 01:37    [11843192]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
таких слота 4 штуки
Guest
Yo.!
Antony GL
область применения - ERP системы. Если быть конкретным - Dynamics AX 09

глупее задачу не найти. SUN помниться говорил, что oracle менее 1% нагрузки требуется плавающая точка ...

Плавающая точка это лишь унифицированный показатель для сравнения производительности.
Там все операции быстрее в 10-10000 раз, да-да там такой разброс. Но вот конкурентный доступ это действительно будет некоторая проблема для всех многоядерников, в том числе и CPU. Но это решат ;)
29 дек 11, 01:39    [11843196]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Edd.Dragon
Member

Откуда: Украина
Сообщений: 6963
ДохтаР
Если бы она скзал, что собирается рисовать и рендерить очередного Шрека, то да.

Рендеринг - далеко не единственная сфера применения.
Но вот приложить туда СУБД действительно антивыхлопная идея.
29 дек 11, 01:42    [11843202]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Edd.Dragon
Member

Откуда: Украина
Сообщений: 6963
таких слота 4 штуки
Плавающая точка это лишь унифицированный показатель для сравнения производительности.
Там все операции быстрее в 10-10000 раз, да-да там такой разброс.

Вот заливать не надо.

Там - ковш эксватора, способный за одно движение извлеч 1 кубометр грунта. Но это абсолютно бесполезно, когда надо вырыть небольшую в диаметре, но длинную дыру закрытым способом.

Так вот, если найдешь в СУБД надобность тупо рыть, чем больше тем лучше - тогда GPU сделает это быстрее CPU. ЧТо в 10 раз, что в 100. Что может и в 1000. Зависимо от моделей того и другого.
29 дек 11, 01:47    [11843210]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
таких слота 4 штуки
Guest
Edd.Dragon
таких слота 4 штуки
Плавающая точка это лишь унифицированный показатель для сравнения производительности.
Там все операции быстрее в 10-10000 раз, да-да там такой разброс.

Вот заливать не надо.

Там - ковш эксватора, способный за одно движение извлеч 1 кубометр грунта. Но это абсолютно бесполезно, когда надо вырыть небольшую в диаметре, но длинную дыру закрытым способом.

Так вот, если найдешь в СУБД надобность тупо рыть, чем больше тем лучше - тогда GPU сделает это быстрее CPU. ЧТо в 10 раз, что в 100. Что может и в 1000. Зависимо от моделей того и другого.

Знаток-знаток, ковшы... экскаваторы...
29 дек 11, 01:50    [11843220]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Росгоснанораспилтрест
Member [заблокирован]

Откуда: Главпилорама
Сообщений: 2421
Edd.Dragon
таких слота 4 штуки
Плавающая точка это лишь унифицированный показатель для сравнения производительности.
Там все операции быстрее в 10-10000 раз, да-да там такой разброс.

Вот заливать не надо.

Там - ковш эксватора, способный за одно движение извлеч 1 кубометр грунта. Но это абсолютно бесполезно, когда надо вырыть небольшую в диаметре, но длинную дыру закрытым способом.

Так вот, если найдешь в СУБД надобность тупо рыть, чем больше тем лучше - тогда GPU сделает это быстрее CPU. ЧТо в 10 раз, что в 100. Что может и в 1000. Зависимо от моделей того и другого.


Сложные статистические и аналитические запросы, ворочающие сравнительно малыми объемами данных, и делающие это посредством GPU? Сложно представляемо. Ещё более сложно представляется, как это можно запихнуть в обычные современные РСУБД.
29 дек 11, 01:50    [11843221]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Росгоснанораспилтрест
Member [заблокирован]

Откуда: Главпилорама
Сообщений: 2421
О! Кастую БАЗИСТРА в тред!!!1
29 дек 11, 01:51    [11843222]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54803

Росгоснанораспилтрест
Узким местом в современных системах хранения данных являются именно эти самые системы
хранения, тобишь - дисковые массивы.И 90% производительности зависит от них. Если надо,
шоп было мегабыстро, и при этом обслуживало 100500 клиентов - Oracle RAC + SAN за 10005000
бабла, и не иначе.

Ты бы эта... определился уже: или системы хранения данных - узкое место, или мегабыстро
это RAC, в несколько рыл насилующий одну и ту же систему хранения данных.

Posted via ActualForum NNTP Server 1.5

29 дек 11, 02:23    [11843288]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
GPGPU это для массивно-параллельных вычислений, shared-nothing, то, что легко шардится
что это может быть - например сетевой рутер, файрволл, SSL-терминатор
какой-то сверхбыстрый messaging cloud, т.е. продукт типа RabbitMQ

а также - паролеломалка, распознаватор образов и звуков, робот для low latency trading,
в общем много можно придумать интересных вещей, особенно если писать можно бы было на высокоуровневом ФП-языке

но не базы данных
ERP - это в основном OLTP, а OLTP это shared everything, локи и транзакции
на модель GPGPU ложится, прямо скажем, не особо
ниже уже правильно сказали, что основные затыки по производительности - это вовсе даже не CPU, а I/O, т.е. в дисковой подсистеме
т.е. купите для ваших серверов хайэндовые серверные SSD - и ещё лет несколько никаких забот знать не будете
29 дек 11, 04:41    [11843415]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
А объясните мне идиоту, что мешает... Берем наш любимый LEFT JOIN и простым перебором.... Если я что-то понимаю, то сравнить одновременно 1К значений друг с другом быстро - это как раз GPU. А если в ON стоит еще вычислительное условие, то - еще быстрее. В то-же время, если у вас OLTP (А Постгре, о котором тут говорится, все-таки заточен под OLTP), то вся база у вас в оперативке и именно селекты-то с джойнами - это больше CPU задача. И вот тут-то выстрелит именно GPU.
30 дек 11, 14:26    [11850652]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Warstone, самолёт потянет 1000 плугов за раз. Вот и приспособь его поле вспахать :)...
30 дек 11, 17:01    [11851392]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Edd.Dragon
Member

Откуда: Украина
Сообщений: 6963
Warstone
А объясните мне идиоту, что мешает... Берем наш любимый LEFT JOIN и простым перебором.... Если я что-то понимаю, то сравнить одновременно 1К значений друг с другом быстро - это как раз GPU.

1. GPU - это применить к 1M - 1G значений какую-либо операцию. Например посчитать ax или ax+b (это тоже 1 операция в GPU).
Сравнения(ветвления) - враг GPU. Даже в самом поверхностном знакомстве с архитектурой мы узнаем, что выполнение делится на warp-ы - блоки,выполняющие на пачкой из 32 потоков одну операцию. Если внутри warp-а хотя бы 1 поток в if-е пойдет одним путем, а остальные 31 потоков - другим. Придется выполнить и то, и другое для всех 32 потоков. Копая глубже, наткнемся и на другие проблемы.

2. Прежде чем что-то посчитать на GPU, нужно перелить ему данные из оперативки в видеопамять. После рассчетов - забрать обратно. Поэтому когда ты сравниваешь производительность CPU с GPU, то фактически ты сравниваешь: "подготовить данные в оперативке, посчитать на CPU" и "подготовить данные в оперативке, закинуть в видеопамять, посчитать на GPU, вернуть результат в оперативку". Передача данных напрямую зависит от скорости и незанятости другими потоками твоей оперативки - PCI-Ex и видеопамять всяко быстрее и скорость упирается в оперативку. Перегнать гиг данных в видеопамять из DDR2-800 - это порядка секунды. Если результат - не скаляр, а тоже вектор, то и назад будем забирать допустим пол гига - еще пол секунды. Если над этим гигом чисел надо выполнить с десяток векторных операций, то ничего ты не выиграешь. Разве что, не с целью ускорить, а с целью разгрузить CPU. Т.е. закинув данные в GPU, следует как можно дольше над ними там издеваться. Т.е. соотношение "кол-во операций на единицу данных" должно быть как можно больше.

Не предназначен GPU для перемещения чисел в памяти по какому-то условию. Он предназначен для их многократного массового измения.
30 дек 11, 18:36    [11851612]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Edd.Dragon
Warstone
А объясните мне идиоту, что мешает... Берем наш любимый LEFT JOIN и простым перебором.... Если я что-то понимаю, то сравнить одновременно 1К значений друг с другом быстро - это как раз GPU.

1. GPU - это применить к 1M - 1G значений какую-либо операцию. Например посчитать ax или ax+b (это тоже 1 операция в GPU).
Сравнения(ветвления) - враг GPU. Даже в самом поверхностном знакомстве с архитектурой мы узнаем, что выполнение делится на warp-ы - блоки,выполняющие на пачкой из 32 потоков одну операцию. Если внутри warp-а хотя бы 1 поток в if-е пойдет одним путем, а остальные 31 потоков - другим. Придется выполнить и то, и другое для всех 32 потоков. Копая глубже, наткнемся и на другие проблемы.

2. Прежде чем что-то посчитать на GPU, нужно перелить ему данные из оперативки в видеопамять. После рассчетов - забрать обратно. Поэтому когда ты сравниваешь производительность CPU с GPU, то фактически ты сравниваешь: "подготовить данные в оперативке, посчитать на CPU" и "подготовить данные в оперативке, закинуть в видеопамять, посчитать на GPU, вернуть результат в оперативку". Передача данных напрямую зависит от скорости и незанятости другими потоками твоей оперативки - PCI-Ex и видеопамять всяко быстрее и скорость упирается в оперативку. Перегнать гиг данных в видеопамять из DDR2-800 - это порядка секунды. Если результат - не скаляр, а тоже вектор, то и назад будем забирать допустим пол гига - еще пол секунды. Если над этим гигом чисел надо выполнить с десяток векторных операций, то ничего ты не выиграешь. Разве что, не с целью ускорить, а с целью разгрузить CPU. Т.е. закинув данные в GPU, следует как можно дольше над ними там издеваться. Т.е. соотношение "кол-во операций на единицу данных" должно быть как можно больше.

Не предназначен GPU для перемещения чисел в памяти по какому-то условию. Он предназначен для их многократного массового измения.
Спасибо, в курсе про варпы и т.д. Но вообще-то вы не совсем правы. (Совсем не правы). Кеш можно держать в GPU через текстурные массивы. Да, до них доступ медленней, чем до тех 16К регистров, но он быстрее чем "загрузил из оперативки". То есть если у вас 2-х уровневый кеш (память GPU, память основная, ну и диск), то проблема "переслать, посчитать, отослать обратно" становится "переслать недостающее, посчитать, отослать обратно если надо". Что гораздо быстрее.

По поводу if'ов... Гуглите функциональный язык программирования. Там нету ifов (а вот так).

Все "проблемы" рассчетов на GPU - это в 80% - нежелание программистов "думать" по другому. Да, для GPU нужно решать задачи не так, как принято. Но это не значит что GPU из-за этого - гавно.
31 дек 11, 02:54    [11852584]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Кстати... Если все упирается в оперативку(а не в скорость общеня между оперативной и PCI-E 16x), то вы получите те-же задержки и при просчете на CPU (У вас-же нету 1Гб кеша 3-го уровня), только вот на CPU зп рпз можно будет обрабатывать 16 байт данных (SSE4+, 128 бит регистры), а на GPU до 64Кб за такт (16К потоков по 4 байта вроде). Идея должна быть ясна, я думаю.
31 дек 11, 03:10    [11852591]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Edd.Dragon
Member

Откуда: Украина
Сообщений: 6963
Warstone
Все "проблемы" рассчетов на GPU - это в 80% - нежелание программистов "думать" по другому. Да, для GPU нужно решать задачи не так, как принято. Но это не значит что GPU из-за этого - гавно.

Да как не думай, но GPU изначально задумывался и выпиливался как тысячерукий землекоп. Сознанием этот факт не изменить. И даже пиарщики nVidia в Best Practices не осмелились заявить, что ускорить можно почти все, что угодно, при должном подходе.

А вот о говне не понял. Не было такого.


автор
Гуглите функциональный язык программирования. Там нету ifов (а вот так).

1. И куда мне дальше это знание прикладывать?
2. Да и не переводить же все мировое сообщество на ФП из-з GPU...


автор
Кстати... Если все упирается в оперативку(а не в скорость общеня между оперативной и PCI-E 16x), то вы получите те-же задержки и при просчете на CPU (У вас-же нету 1Гб кеша 3-го уровня), только вот на CPU зп рпз можно будет обрабатывать 16 байт данных (SSE4+, 128 бит регистры), а на GPU до 64Кб за такт (16К потоков по 4 байта вроде). Идея должна быть ясна, я думаю.

Ясна. Но тем не менее, это имеет смысл только при хорошем соотношении "оп./байт" - иначе и GPU, и CPU будут справляться с обработкой по мере поступления данных. При чем у CPU будет фора - не нужно писать ни буквы кода, чтобы наладить порционную подачу данных в кеш и синхронизацию выполнения. Если аналогичную подачу данных не наладить для GPU, он может "опозориться". И CPU есть обязательно и можно 4-ядерник сменить на 8-ядерник если что, а GPU надо "внедрять". Справшивается, зачем в таком случае было городить огород? Чтобы было чем занять программистов? Суть то - ускорить, а не переложить с больной головы на здоровую, потратив на это деньги.

Вот например, лучшая на сегодня RadixSort на GTX480 примерно лишь в 4 раза быстрее 4-ядерного i7. Без учета транспортивки. И достигается это преймущество при объеме массива от 20 млн. ключей. При чем, аналогичная сортировка из SDK nVidia конечно же медленнее. Т.е. допустим в 2-2.5 раза быстрее i7. А на сайте мы вдруг обнаруживаем цифры 10х и 100х (Ожидаемое увеличение скорости в сравнении с четырехъядерной системой на базе CUDA) . Постеснялись хоть бы )))

----------------------------------

Тем не менее, кто смелый - есть что внедрять и куда деньги потратить. Было бы любопытно услышать отзывов и узнать, какие необходимы нагрузки для получения профита:
http://www.parstream.com/en/product/features/features.html
31 дек 11, 05:58    [11852655]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
AKM66
Member

Откуда:
Сообщений: 73
На самом деле в реляционных базах есть смысл перекладывать часть вычислений на GPU. Дело в том что традиционные базы данных выполняют операции на каждой записи, а GPU может выполнить операцию сразу надо всей колонкой. Очень быстро.
Еще одна область где можно достигнуть большей производительности - это сжатие данных. Если применять параллелизуемые алгоритмы то скорость сжатия/расжатия достигает десятков гигабайтов в секунду на обычной видеокарте. Ни в Оракле ни в DB2 таких технологий пока нет.
Чтоб не быть голословным, я набросал вчера на коленке код для реляционного движка использующего GPU. И вот некоторые бенчмарки моего обычного PC с NVIDIA GTX 260 супротив самых быстрых в мире серверов :

Бенчмарк TPC-H Query 1 Scale Factor 300 - примерно 1800000000 записей :

Мой PC : Pentium E5200 , 4 GB of RAM, 1x2TB hard drive , NVidia GTX 260
Top #10 TPC-H 300GB non-clustered performance result : MS SQL Server 2005 : Hitachi BladeSymphony (8 CPU/8 Cores), 128 GB of RAM, 290x36GB 15K rpm drives
Top #7 TPC-H 300GB non-clustered performance result : MS SQL Server 2005 : HP ProLiant DL585 G2 (4 CPU/8 Cores), 128 GB of RAM, 200x36GB 15K rpm drives :

Я - 178 секунд
Top#10 - 485 секунд
Top#7 - 309 секунд

Так что есть смысл перекладывать вычисления на GPU.
31 дек 11, 10:03    [11852702]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
DeathHand
Member

Откуда: Мск>СПБ>Врн
Сообщений: 2705
AKM66
я набросал вчера на коленке код для реляционного движка использующего GPU


От оно че...
31 дек 11, 13:44    [11852843]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Yo.!
Guest
AKM66,

поскольку вы на коленках не парились ни с блокировками, ни с вычислением контрольной суммы блока, ни уровнями изолированности ни с еще тысячей вещей увеличивающей в промышленной субд размер блоков, то и результ ваш мало интересен ...
31 дек 11, 13:54    [11852849]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
AKM66
Member

Откуда:
Сообщений: 73
Yo.!
AKM66,

поскольку вы на коленках не парились ни с блокировками, ни с вычислением контрольной суммы блока, ни уровнями изолированности ни с еще тысячей вещей увеличивающей в промышленной субд размер блоков, то и результ ваш мало интересен ...


А с этим не парятся многие аналитические базы данных. Очень часто нужно просто получить результат на основе уже загруженных данных. Транзакционные базы - это совсем другая история, и никто и не пытается перенести их на GPU. Пока что.
31 дек 11, 14:38    [11852915]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
1000-10000 раз
Guest
Edd.Dragon
Вот например, лучшая на сегодня RadixSort на GTX480 примерно лишь в 4 раза быстрее 4-ядерного i7. Без учета транспортивки. И достигается это преймущество при объеме массива от 20 млн. ключей. При чем, аналогичная сортировка из SDK nVidia конечно же медленнее. Т.е. допустим в 2-2.5 раза быстрее i7. А на сайте мы вдруг обнаруживаем цифры 10х и 100х (Ожидаемое увеличение скорости в сравнении с четырехъядерной системой на базе CUDA) . Постеснялись хоть бы )))

Сортировка это один из самых труднораспараллеливаемых алгоритмов.
И чего им стесняться если действительно заточенные под GPU задачи, например рендеринг, получают ускорение в 1000-10000 раз.

AKM66, здесь Bazist и без GPU получал такое ускорение для своей СУБД :)
Мало того, он открыл для себя std::map и подумал что это алгоритм сжатия.
31 дек 11, 15:14    [11852961]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Ну выполнение агрегатов точно быстрее на GPU. Равно как и WINDOW функций. А вот сортировка - да... тут сложно. Хотя... Надо подумать... Но я все-равно не верю, что нельзя на GPU переложить часть работы, когда транзакции удовлетворены, видимость данных подтверждена (кстати, не полностью, и если это MVCC) и можно отправлять задачу на GPU.

Но вообще... Ждем Inter Fermi или как оно там... Математический сопроцессор с 96 ядрами уровня П3. Говорили будет в этом году. Мнямка!
31 дек 11, 16:38    [11853119]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54803

Warstone
Ну выполнение агрегатов точно быстрее на GPU.

Да неужели? А исходные данные для этих агрегатов ты собираешься из ГСЧ брать или всё же c
диска? Как на твоём GPU вычислить это:
select count(*), sum(a), avg(b) from t where d >= date '01.01.2001'
group by d order by d

Posted via ActualForum NNTP Server 1.5

31 дек 11, 16:46    [11853137]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Edd.Dragon
Member

Откуда: Украина
Сообщений: 6963
1000-10000 раз
И чего им стесняться если действительно заточенные под GPU задачи, например рендеринг, получают ускорение в 1000-10000 раз.

Нет, речь именно о радиксе. На счет векторных вычислений конечно стесняться им нечего.

Точно так же и по поводу перебора паролей (гораздо более GPU-шной задачи) цифры маркетологи хорошенько завышают.
Это я все к тому - что официальные материалы говорят одно, а потом сообщество под стимулом спортивного интереса тратит время и достигает другого. Потому одним кажется, что это панацея, другие же понимают, что чем менее "профильная" задача для GPU, тем дороже обходится ее реализация с точки зрения бизнеса. Там же, где в этом есть толк - та же аналитика - давно есть решения, которые с успехом работают. Правда никто не кричит об ускорении в 100 и в 1000 раз. Даже 10х - это много в промышленных масштабах.

Ну а векторными вычислениями видеокарты занимаются, как говорится, издревле, еще до своей универсализации. И сравнивать это их прямое предназначение с CPU дабы доказать очевидно, никому в голову не придет.
31 дек 11, 17:13    [11853194]     Ответить | Цитировать Сообщить модератору
 Re: СУБД, использующая вычисления на GPU.  [new]
Edd.Dragon
Member

Откуда: Украина
Сообщений: 6963
Warstone
Но вообще... Ждем Inter Fermi или как оно там... Математический сопроцессор с 96 ядрами уровня П3. Говорили будет в этом году. Мнямка!

Larrabee
31 дек 11, 17:17    [11853205]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить