我一直在阅读有关 Nvidia Cuda 的信息，并且我看到了一些关于 SO 的问题，人们已经回答了这些问题，其中包括“您的问题不适合在 GPU 上运行”的评论。
在我的办公室，我们有一个数据库，其中包含我们查询的大量记录，而且可能需要很长时间。我们已经实现了 SELECT DISTINCT 或它们对值应用大写函数的 SQL 查询。作为对 Cuda 的介绍，我考虑编写一个程序，该程序可以在 GPU 上获取所有字符串并将它们大写。
我一直在读一本关于 Cuda 的书，作者谈到试图让 GPU 内核尽可能多地执行，以隐藏通过 PCI 总线读取数据或将东西放入全局内存中的延迟。由于内存非常小，而且我有数百万个不同的单词，我自然会让总线饱和并让 GPU 内核饿死。
这是一个不会从显卡而不是 CPU 获得出色性能提升的问题吗？
谢谢，
米
由于您的操作/传输比率为 O(1)，因此您将在全局内存访问中遇到相当大的瓶颈。
可能更值得在 GPU 上进行比较，因为它的操作/传输比要大得多。
当您将字符串加载到共享内存中以执行此操作时，您还可以将其大写，有效地包括您之前想要做的事情，等等。
我不禁觉得基于 CPU 的实现可能会给你更好的性能。至少，它会减少你的头痛……
我们已经实现了 SELECT DISTINCT 或它们对值应用大写函数的 SQL 查询。
您是否考虑过在表中添加一个包含预先计算的大写字符串版本的列？
我倾向于认为，如果您的数据库完全在 RAM 中并且查询仍然需要“永远”，那么您的数据库可能没有正确构建和索引。检查您的查询计划。
我认为，在正常情况下，您的选择被索引整齐地覆盖，您将无法使用 GPU 进行优化。但也许有些东西可以针对 GPU 进行优化，例如需要表扫描的查询，例如带有通配符的 LIKE 查询和基于计算（值小于等）选择行的查询。当连接列具有许多重复值时，甚至可能是诸如具有许多连接的查询之类的事情。
这种实现的关键是在 GPU 上保留数据库中某些数据的镜像，并使其与数据库保持同步。然后对该数据运行诸如并行缩减之类的操作，以得出行 ID，然后用于针对常规数据库的选择。
不过，在采取这样的步骤之前，我将探索使用时空权衡的数据库查询优化的无数可能性。