Можно ли ускорить (динамический) запрос LINQ с помощью GPU?

Ответ 1

Я окончательно отвечу о Брахме, так как это моя библиотека, но она, вероятно, относится и к другим подходам. Графический процессор не знает объектов. Эта память также в основном полностью отделена от памяти ЦП.

Если у вас есть БОЛЬШОЙ набор объектов и вы хотите работать с ними, вы можете упаковать только те данные, которые хотите работать, в буфер, подходящий для используемого вами графического процессора /API, и отправить его для обработки,

Обратите внимание, что это сделало бы две круглые поездки по интерфейсу памяти CPU-GPU, поэтому, если вы не выполняете достаточную работу на графическом процессоре, чтобы сделать это стоящим, вы будете медленнее, чем если бы вы просто использовали CPU в первое место (например, образец выше).

Надеюсь, что это поможет.

Ответ 2

Графический процессор действительно не предназначен для всех целей общего назначения, особенно с объектно-ориентированными проектами, подобными этому, и фильтрация произвольного набора данных, подобных этому, действительно не подходит.

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

В этом случае вам нужно будет скопировать все данные в графический процессор, чтобы выполнить эту работу, и перестроить его в той или иной форме, какой будет понимать GPU, что, вероятно, будет более дорогостоящим, чем просто выполнение фильтра в программном обеспечении в первое место.

Вместо этого я бы рекомендовал использовать PLINQ для ускорения запросов такого рода. Если ваш фильтр является потокобезопасным (что должно быть для любой работы с графическим процессором...), это, скорее всего, лучший вариант для оптимизации запросов общего назначения, поскольку для копирования данных ваши данные не потребуются. PLINQ работал бы, переписывая ваш запрос как:

var result = myList.AsParallel().Where(x => x.SomeProperty == SomeValue);

Если предикат является дорогостоящей операцией или сбор очень велик (и легко разбивается на разделы), это может значительно улучшить общую производительность по сравнению со стандартными LINQ to Objects.

Ответ 3

GpuLinq

Основная задача GpuLinq - демократизировать программирование GPGPU через LINQ. Основная идея заключается в том, что мы представляем запрос как дерево выражений, а после различных преобразований-преобразований мы скомпилируем его в быстрый код ядра OpenCL. Кроме того, мы предоставляем очень простой в работе API без необходимости возиться с деталями API OpenCL.

https://github.com/nessos/GpuLinq

Ответ 4

Простой ответ для вашего случая использования - нет.

1) Нет решения для такого рода рабочей нагрузки, даже в необработанном linq для объекта, а тем более в чем-то, что заменит вашу базу данных.

2) Даже если вы были в порядке с загрузкой всего набора данных одновременно (это требует времени), все равно будет намного медленнее, так как у GPU высокая пропускная способность, но их доступ имеет высокую задержку, поэтому, если вы смотрите на "очень" быстрые решения" GPGPU часто не являются ответом, так как просто подготовка/отправка рабочей нагрузки и возвращение результатов будут медленными, и в вашем случае, вероятно, также необходимо сделать куски.

Ответ 5

select *
from table1  -- contains 100k rows
left join table2 -- contains 1M rows
on table1.id1=table2.id2 -- this would run for ~100G times 
                         -- unless they are cached on sql side
where table1.id between 1 and 100000 -- but this optimizes things (depends)

можно было бы превратить в

select id1 from table1 -- 400k bytes if id1 is 32 bit 
-- no need to order

сохранено в памяти

select id2 from table2 -- 4Mbytes if id2 is 32 bit
-- no need to order

хранится в памяти, оба массива отправляются в gpu с использованием ядра (cuda, opencl), как показано ниже

int i=get_global_id(0); // to select an id2, we need a thread id
int selectedID2=id2[i];
summary__=-1;
for(int j=0;j<id1Length;j++)
{
      int selectedID1=id1[j];
      summary__=(selectedID2==selectedID1?j:summary__); // no branching
}
summary[i]=j; // accumulates target indexings of 
"on table1.id1=table2.id2" part.

На стороне хоста вы можете сделать

 select * from table1 --- query3

и

 select * from table2 --- query4

затем используйте список id из gpu, чтобы выбрать данные

 // x is table1 ' s data
 myList.AsParallel().ForEach(x=>query3.leftjoindata=query4[summary[index]]);

Код gpu не должен быть медленнее, чем 50 мс для gpu с постоянной памятью, возможностью глобального вещания и несколькими тысячами ядер.

Если для фильтрации используется любая тригонометрическая функция, производительность будет быстро снижаться. Кроме того, когда слева объединенные таблицы подсчет строк делает сложностью O (m * n), то миллионы против миллионов будут намного медленнее. Здесь важна пропускная способность памяти GPU.

Edit: Единственная операция gpu.findIdToJoin(таблица1, таблица2, "id1", "id2" ) на моем hd7870 (1280 ядер) и R7-240 (320 ядер) с "таблицей продуктов (строки 64k)" и "таблица категорий ( 64k строк)" (фильтр левого соединения) занял 48 миллисекунд с неоптимизированным ядром.

Ado.Net "nosql" стиль linq-join занял более 2000 мс только с 44 тыс. продуктов и 4 тыс. категорий категорий.

Edit-2:

левое соединение с условием поиска строки получает от 50 до 200 x быстрее на gpu, когда таблицы вырастают до 1000 строк, каждый из которых имеет по меньшей мере сотни символов.