Algorithm 通用算法的GPU与CPU性能

我想知道是否有任何通用算法（排序、搜索、图形等）已移植到OpenCL（或任何GPU语言），以及性能与CPU执行的相同算法相比如何。我对结果（数字）特别感兴趣

---

谢谢

GPU是高度专业化的硬件，设计用于很好地完成一小部分任务，并且高度并行化。这基本上是算术（特别是单精度浮点数学，尽管较新的GPU在双精度方面做得很好）。因此，它们只适用于特定的算法。我不确定排序是否适合该类别（至少在一般情况下）

更常见的例子是金融工具的定价，大量的矩阵数学，甚至（通过蛮力）。尽管如此，我还是找到了

另一个常被引用的例子是，但它将苹果与橙子进行比较。GPU的工作单元与CPU通常的工作单元不同（并且非常有限）。

请看一下：

推力是一个CUDA并行库 带接口的算法 类似C++标准模板 图书馆（STL）。推力提供了一个 灵活的GPU高级接口 大大增强 开发人员生产力

---

NVidia的网站上有类似的东西。请记住，有些事情（如排序）需要特殊的算法来实现高效的并行性，并且可能没有单核上的非线程算法那么高效。

请小心，对于GPGPU引用的任何性能数字都要非常小心。许多人喜欢发布令人印象深刻的数字，这些数字没有考虑到将输入数据从CPU传输到GPU和将输出数据返回所需的传输时间，这两者都会跨越PCIe瓶颈。

在许多接受图像上传的网站上，图像大小调整必须很常见

调整2600英寸x 2000英寸2MB jpeg图像（至512x512）的大小需要23.5毫秒的C#时间，使用绝对最低质量选项和最近邻采样。使用的函数是基于

graphics.DrawImage（）

的函数。CPU使用率也为%21.5

在C#端获取“rgba字节数组”提取并将其发送到GPU，在GPU中调整大小并将结果返回到图像需要6.3毫秒，CPU使用率为%12.7。这是用一个便宜55%的gpu完成的，它只有320个内核

只有3.73倍的加速倍增器

这里的限制因素是，将提取的20MB rgb数据（jpeg只有2MB！）发送到GPU。这一耗时部分几乎占总时间的90%，包括C端字节数组提取！所以，若提取部分也可以在GPU中完成，那个么至少会有30倍的加速

30倍还不错

然后，您可以通过管道将提取层与调整大小层连接起来，以隐藏内存复制延迟，从而获得更快的速度！这可能是40X-50X

然后提高采样的质量（例如双三次采样而不是最近邻采样），您在GPU方面会有更多的优势。添加5x5高斯滤波器只增加了0.77百万秒。CPU将获得更高的时间，尤其是当所需的高斯参数与C#.Net实现不同时

---

即使您对加速比不满意，卸载到GPU并在CPU上有一个“空闲内核”仍然有利于将更多工作推送到该服务器

现在再加上GPU功耗水平的事实（本例中为30W与125W），这将更有优势

---

CPU很难在竞争中获胜

 C[i]=A[i]+B[i]

当双方都在优化代码上运行时，您仍然可以将一半阵列卸载到GPU，同时使用CPU+GPU更快地完成测试

---

---

GPU不是为非统一工作而构建的。GPU有很深的管道，因此由于分支而在失速后站立需要很长时间。此外，SIMD类型的硬件强制它对其上的所有工作项执行相同的操作。当一个工作项执行与该组不同的操作时，它会失去跟踪并在整个SIMD管道中添加气泡，或者其他工作项只是等待同步点。因此，分支会影响深度和广度管道区域，并使其在完全混乱的情况下比CPU更慢。

这是事实，但NVIDIA网页上的许多示例都是完整的应用程序，并且肯定包含这些传输时间。真正令人担忧的是：基准测试中的CPU版本优化程度如何？推力刚刚发布了1.1版。