Nvidia Cuda Program - 我的问题适合 Cuda 架构吗？答案

【问题标题】：Nvidia Cuda Program - is my prob appropriate for the Cuda architecture?Nvidia Cuda Program - 我的问题适合 Cuda 架构吗？
【发布时间】：2012-04-23 20:08:19
【问题描述】：

我一直在阅读有关 Nvidia Cuda 的信息，并且我看到了一些关于 SO 的问题，人们已经回答了其中包括“您的问题不适合在 GPU 上运行”的评论。

在我的办公室，我们有一个数据库，其中包含我们查询的大量记录，而且可能需要很长时间。我们已经实现了 SELECT DISTINCT 或它们对值应用大写函数的 SQL 查询。作为对 Cuda 的介绍，我考虑编写一个程序，该程序可以在 GPU 上获取所有字符串并将它们大写。

我一直在阅读一本关于 Cuda 的书，其中作者谈到尝试使 GPU 内核尽可能多地执行，以隐藏通过 PCI 总线读取数据或将内容放入全局内存中的延迟。由于内存非常小，而且我有数百万个不同的单词，我自然会让总线饱和并让 GPU 内核饿死。

这是一个不会从显卡而不是 CPU 获得惊人性能提升的问题吗？

谢谢，

【问题讨论】：

大部分查询时间不会是由于磁盘 I/O 的速度造成的吗？如果答案是肯定的，那么减少查询时间的唯一方法就是提高 I/O 吞吐量。 GPU 对此无能为力。
你说的完全正确。让我们再添加一个假设，假设我在一个具有 64 GB RAM 的服务器上，并且我尝试将所有数据保存在内存中。
还是没有。您的任务不是计算成本高，而是内存成本高。因此 GPU 不是一个好的选择。如果您的数据已经在内存中，OpenMP 可能更适合。
@mj_：这可能不会改变分析。现在您已将瓶颈从磁盘 I/O 移至 PCI-e 总线。但是传输数据的速度可能仍然是性能限制因素，而不是与查询本身相关的实际计算。

标签： cuda gpu nvidia

【解决方案1】：

我们已经实现了 SELECT DISTINCT 的 SQL 查询，或者它们对一个值应用大写函数。

您是否考虑过在表中添加一列，其中包含预先计算的大写字符串版本？

我倾向于认为，如果您的数据库完全在 RAM 中并且查询仍然需要“永远”，那么您的数据库可能没有正确构建和索引。检查您的查询计划。

我认为，在正常情况下，如果您的选择被索引整齐地覆盖，您将无法使用 GPU 进行优化。但是也许有些东西可以针对 GPU 进行优化，例如需要表扫描的查询，例如带有通配符的 LIKE 查询和基于计算（值小于等）选择行的查询。当连接列有许多重复值时，甚至可能会出现诸如具有许多连接的查询之类的事情。

这种实现的关键是在 GPU 上保留数据库中某些数据的镜像，并使其与数据库保持同步。然后对该数据运行诸如并行缩减之类的操作，以得出行 ID，然后用于针对常规数据库进行选择。

不过，在采取这样的步骤之前，我将探索使用时空权衡的数据库查询优化的无数可能性。

【讨论】：

我会说计算 LIKE 查询可能会导致 GPU 上的过多分支非常有效。

【解决方案2】：

由于您的操作/传输比率为 O(1)，因此您将在全局内存访问中遇到相当大的瓶颈。

在 GPU 上进行比较可能更有价值，因为它的运算/传输比要大得多。

当您将字符串加载到共享内存中以执行此操作时，您也可以将其大写，有效地包括您之前想要做的事情，以及更多。

我不禁觉得基于 CPU 的实现可能会给您带来更好的性能。至少，它会减少你的头痛......

【讨论】：