cuda - 如果我们有 GPGPU，为什么要使用 SIMD？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




既然我们拥有 GPGPU 和 CUDA 和 OpenCL 等语言，那么多媒体 SIMD 扩展(SSE/AVX/NEON)还有用吗？

我最近阅读了一篇关于如何使用 SSE 指令来加速排序网络的文章。我认为这很简洁，但是当我告诉我的计算机首席教授时，他笑着说在 GPU 上运行类似的代码会破坏 SIMD 版本。我不怀疑这一点，因为 SSE 非常简单，而且 GPU 是具有更多并行性的大型高度复杂的加速器，但它让我思考，是否有许多场景中多媒体 SIMD 扩展比使用 GPU 更有用？

如果 GPGPU 使 SIMD 变得多余，英特尔为什么要增加对 SIMD 的支持？ SSE 是 128 位，现在 AVX 是 256 位，明年将是 512 位。如果 GPGPU 能够更好地处理具有数据并行性的代码，那么英特尔为什么要插入这些 SIMD 扩展？他们可能能够将等效资源(研究和领域)放入更大的缓存和分支预测器中，从而提高串行性能。

为什么使用 SIMD 而不是 GPGPU？

Answer 1

绝对 SIMD 仍然相关。

首先，SIMD 可以更容易地与标量代码互操作，因为它可以直接读写相同的内存，而 GPU 要求数据上传到 GPU 内存才能访问。例如，通过 SIMD 向量化像 memcmp() 这样的函数很简单，但是通过将数据上传到 GPU 并在那里运行来实现 memcmp() 是荒谬的。延迟将是毁灭性的。

其次，SIMD 和 GPU 都不擅长处理高度分支的代码，但 SIMD 的糟糕程度要低一些。这是因为 GPU 在单个指令调度程序下将多个线程(“warp”)分组。那么当线程需要采取不同的路径时会发生什么:在一个线程中采用 if 分支，而在另一个线程中采用 else 分支？这被称为“分支分歧”并且它很慢:所有“if”线程在“else”线程等待时执行，然后“else”线程在“if”线程等待时执行。当然，CPU 内核没有这个限制。

结果是 SIMD 更适合可能被称为“中间工作负载”的工作负载:直到中等大小的工作负载，具有一些数据并行性，访问模式中的一些不可预测性，一些分支。 GPU 更适合具有可预测执行流和访问模式的超大型工作负载。

(还有一些外围原因，例如更好地支持 CPU 中的 double 浮点。)