А объясните мне идиоту, что мешает... Берем наш любимый LEFT JOIN и простым перебором.... Если я что-то понимаю, то сравнить одновременно 1К значений друг с другом быстро - это как раз GPU. А если в ON стоит еще вычислительное условие, то - еще быстрее. В то-же время, если у вас OLTP (А Постгре, о котором тут говорится, все-таки заточен под OLTP), то вся база у вас в оперативке и именно селекты-то с джойнами - это больше CPU задача. И вот тут-то выстрелит именно GPU.

Edd.DragonWarstoneА объясните мне идиоту, что мешает... Берем наш любимый 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 из-за этого - гавно.

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

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

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