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

Я отвечу определенно о Брахме, поскольку это моя библиотека, но, вероятно, это применимо и к другим подходам. GPU ничего не знает об объектах. Его память также в основном полностью отделена от памяти процессора.

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

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

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

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

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

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

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

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

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

GpuLinq

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

https://github.com/nessos/GpuLinq

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

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

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

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

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

Изменить: Одна операция gpu.findIdToJoin(table1,table2,"id1","id2") на моем hd7870(1280 ядер) и R7-240(320 ядер) с таблицей продуктов(64k rows)» и «таблица категорий (64k строк)» (левый фильтр соединения) заняли 48 миллисекунд с неоптимизированным ядром.

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

Правка-2:

левое соединение с условием поиска строки становится в 50-200 раз быстрее на GPU, когда таблицы вырастают до 1000 строк, каждая из которых содержит не менее сотни символов.

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

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

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