我一直在阅读关于Nvidia Cuda的文章，并且我看到过一些关于人们已经回答了一些问题，他们在这里回答了“你的问题不适合在GPU上运行”的评论。Nvidia Cuda计划 - 我的Cuda适合Cuda架构吗？
在我的办公室，我们有一个数据库，其中有大量的记录，我们查询到，它可以永远。我们已经实现了SELECT DISTINCT的SQL查询，或者它们对值应用了一个大写函数。作为Cuda的介绍，我想写一个可以在GPU上采用所有字符串并将其大写的程序。
我一直在读一本关于Cuda的书，作者谈论了试图尽可能多地执行GPU内核，以便隐藏通过PCI总线读取数据或将内容放入全局内存的延迟。由于内存大小非常小，并且由于我拥有数百万个不同的单词，因此我自然会饱和总线并使GPU内核挨饿。
这是一个问题，不会从显卡获得奇妙的性能提升，而不是CPU吗？
感谢，
MJ
我们已经实现了SQL查询SELECT DISTINCT或者它们对值应用了大写函数。
你有没有考虑在你的表中添加一个列，预先计算你的字符串的大写版本？
我倾向于认为，如果您的数据库完全在RAM中，并且查询仍然“永远”，那么您的数据库可能没有正确的结构和索引。检查你的查询计划。
我认为，在正常情况下，您的选择被索引整齐地覆盖，您将无法使用GPU进行优化。但也许有些东西可以针对GPU进行优化，比如需要表扫描的查询，例如带通配符的LIKE查询以及基于计算选择行的查询（值小于等）。当连接列有许多重复的值时，甚至可能包含许多连接的查询。
这种实现的关键在于保留GPU上数据库中的一些数据的镜像并使其与数据库保持同步。然后对这些数据运行诸如并行减少操作之类的操作，以获得行ID，然后用于对照常规数据库进行选择。
在采取这一步骤之前，我会探索使用空间时间折衷的数据库查询优化的无数可能性。
我会说计算LIKE查询可能会导致在GPU上分支太多，非常有效。 – 2012-04-12 15:52:39
你将不得不因为你的操作在全局内存访问一个相当大的瓶颈/转移比为O（1）。
在GPU上进行比较可能更有价值，因为它具有更大的操作/传输比率。
当你将一个字符串加载到共享内存中来做到这一点时，你也可以利用它，有效地包括你之前想做的事情，以及更多。
我不禁感到基于CPU的实现可能会给你更好的性能。它至少可以减少头痛的发生......
查询时间大部分时间不是由于磁盘I/O的速度所致？如果答案是肯定的，那么减少查询时间的唯一方法是提高I/O吞吐量。 GPU不能帮上忙。 – talonmies 2012-04-11 14:01:13
你完全正确。让我们再添加一个假设，即我正在一台装有64个RAM的服务器上，并试图将所有数据保存在内存中。 – 2012-04-11 14:26:57
仍然没有。你的任务在计算上并不昂贵，但是内存昂贵。因此GPU不是一个好选择。如果您已将数据存储在内存中，则OpenMP可能更适合。 – Azrael3000 2012-04-11 14:32:55