是否可以使用GPU加速(动态) LINQ查询？

Question

几天来，我一直在寻找关于使用GPU加速LINQ查询的可能性的可靠信息。

到目前为止，我已经“调查”了一些技术：

微软加速器

• Cudafy

• Brahma

简而言之，甚至可以对GPU上的对象进行内存中的过滤吗？

假设我们有一些对象的列表，我们想要过滤这样的内容：

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

对这件有什么建议吗？

提前感谢！

更新

我会尽量更具体地说明我想要达到的目标:)

目标是，使用任何技术，能够以绝对最快的方式过滤对象列表(范围从5万到2000)。

当过滤完成时，我对数据执行的操作(和、最小、最大等)是使用内置的LINQ-方法进行的，对于我们的应用程序来说已经足够快了，所以这不是一个问题。

瓶颈是对数据的“简单”过滤。

更新

我只想补充一下，我已经测试了大约15个数据库，包括MySQL (检查可能的集群方法/ memcached解决方案)、H2、HSQLDB、VelocityDB (目前正在进一步研究)、SQLite、MongoDB等等，在过滤数据的速度方面，没有一个足够好(当然，NO-sql解决方案不提供类似于sql的解决方案，但您可以理解)和/或返回实际数据。

我/我们需要的是：

一个数据库，它能够以200列的格式对数据进行排序，并在不到100 ms的范围内对大约250 000行进行排序。

我目前有一个并行化LINQ的解决方案，它能够(在特定的机器上)在过滤和处理结果时只在每一行上花费！

因此，我们需要在每一行都像sub-nano-second-filtering一样。

1. 为什么看起来只有内存中的LINQ才能提供这个？
2. 为什么不可能呢？

日志文件中的一些数字：

Total tid för 1164 frågor: 2579

这是瑞典语，翻译如下：

Total time for 1164 queries: 2579

本例中的查询是如下所示的查询：

WHERE SomeProperty = SomeValue

这些查询都是在225639行上并行完成的。

因此，在大约2.5秒内，内存中的225639行被过滤了1164次。

这是9,5185952917007032597107300413827e-9秒/行，，但，也包括，实际处理的数字！我们确实计数(不为空)，总计数，和，最小，最大值，Avg，中位数。因此，我们对这些过滤过的行有7个操作。

因此，我们可以说它实际上是比我们尝试过的数据库快7倍，因为我们做而不是在这些情况下做任何聚合的事情！

那么，总之，与内存LINQ过滤相比，为什么数据库过滤数据的能力如此差呢？微软真的做得这么好吗？

虽然内存中的过滤应该更快，但我不希望 sense 认为它更快，这是有道理的。我想知道什么是更快的，如果可能的话，为什么。

Answer 1

我会明确地回答关于梵天的问题，因为它是我的图书馆，但它可能也适用于其他方法。GPU不了解对象。它的内存也基本上与CPU内存完全分离。

如果您确实有一大组对象并希望对它们进行操作，则只能将要操作的数据打包到适合您正在使用的GPU/API的缓冲区中，并将其发送出去进行处理。

请注意，这将在CPU-GPU内存接口上进行两次往返旅行，因此，如果您在GPU上做的工作不够，使之值得，那么您将比最初只使用CPU的速度慢(如上面的示例)。

希望这能有所帮助。

Answer 2

GPU并不是为了所有的通用计算目的而设计的，特别是像这样面向对象的设计，过滤这样的任意数据集合是不合适的。

GPU计算对于在大型数据集上执行相同操作的事情是很好的--这就是为什么像矩阵操作和转换这样的事情可能非常好的原因。在那里，数据复制可以超过GPU上惊人的快速计算能力.

在这种情况下，您必须将所有数据复制到GPU中才能工作，并将其重组为GPU将理解的某种形式，这可能比在软件中执行筛选器要昂贵得多。

相反，我建议使用PLINQ来加速这种性质的查询。如果您的过滤器是线程安全的(对于任何与GPU相关的工作.)对于通用查询优化来说，这可能是一个更好的选择，因为它不需要对数据进行内存复制。PLINQ将通过将查询重写为：

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

如果谓词是一个昂贵的操作，或者集合非常大(并且易于分区)，那么与标准LINQ对象相比，这可以大大提高总体性能。

Answer 3

GpuLinq

GpuLinq的主要任务是通过LINQ实现GPGPU编程的民主化。其主要思想是将查询表示为表达式树，经过各种转换-优化后，我们将其编译成快速的OpenCL内核代码。此外，我们提供了一个非常容易操作的API，而不需要混淆OpenCL API的细节。

https://github.com/nessos/GpuLinq