你的CPU可能是四核的，但你知道今天有些显卡有超过200个内核吗？我们已经看到了当今显卡的GPU在图形方面的功能。现在它们也可用于非图形任务，在我看来，结果简直令人惊讶。一种适用于并行性的算法在GPU上可能比在CPU上更快，更快。
有一些技术可以实现所有这些：
1。）NVidia的 CUDA 。它似乎是最知名的，有据可查的。不幸的是，它只适用于NVidia显卡。我已经下载了SDK，尝试了一些样本，并且在CUDA中有一些很棒的东西。但它仅限于NVidia卡这一事实让我质疑它的未来。
2。）ATI Stream 。 ATI相当于CUDA。正如您所料，它只适用于ATI卡。
3。） OpenCL - Khronos集团已经制定了这个标准，但它还处于初级阶段。我喜欢OpenCL的想法。希望它应该得到大多数视频卡制造商的支持，并且应该使交叉视频卡开发变得更加容易。
但是，非图形化GPU编程的其他技术即将到来，最有希望的是什么呢？您是否看到或者您希望将这些技术构建到某些主流开发框架（如.NET）中，以使其更容易实现？
答案 0 :(得分：18)
我认为你可以将下一个DirectX算作另一种使用GPU的方法。
根据我的经验，GPU对于易于并行化的算法来说非常快。我最近在CUDA中优化了一种特殊的图像大小调整算法，在GPU（甚至不是高端版本）上比四核英特尔处理器快100多倍。问题是将数据传送到GPU，然后将结果提取回主存，这两个方向都受到该机器上memcpy（）速度的限制，该速度小于2 GB / s。因此，该算法仅比CPU版本略快......
所以它真的取决于。如果您有一个科学的应用程序，您可以将大部分数据保存在GPU上，并且所有算法都映射到GPU实现，那么很好。否则，我会等到CPU和GPU之间有更快的管道，或者让我们看看ATI的组合芯片是什么......
关于使用哪种技术：我认为一旦你在CUDA中运行你的东西，将它移植到OpenCL（或其他语言）的额外步骤就不那么大了。您通过并行化算法完成了所有繁重的工作，其余的只是一种不同的“味道”
答案 1 :(得分：9)
我预见这项技术将成为流行和主流，但这需要一些时间。我估计大约5到10年。
正如您所正确指出的那样，采用该技术的一个主要障碍是缺少在大多数适配器上运行的通用库 - 包括ATI和nVidia。在此问题得到解决之前，该技术将无法进入主流市场，并将保留在特定硬件上运行的定制应用程序的适当位置。
至于将它与C＃和其他高级托管语言集成 - 这需要更长的时间，但XNA已经证明自定义着色器和托管环境可以在一定程度上混合在一起。当然，着色器代码仍然不在C＃中，这样做有几个主要障碍。
快速执行GPU代码的一个主要原因是它对代码可以做什么和不能做什么有严重的限制，它使用VRAM而不是通常的RAM。这使得很难将CPU代码和GPU代码结合在一起。虽然可以采用变通方法，但它们实际上会抵消性能提升。
我看到的一个可能的解决方案是为C＃创建一个具有其局限性的子语言，编译为GPU代码，并且具有严格定义的与使用C＃代码通信的方式。然而，这与我们已经没有太大的不同 - 由于一些语法糖和标准库函数，编写起来更加舒适。不过，现在这也是很久了。
答案 2 :(得分：7)
蒙特卡洛令人尴尬地平行，但它是金融和科学计算的核心技术。
其中一位受访者表示，大多数现实世界的挑战都无法轻易分解为这些类型的任务。
通过利用可以以令人尴尬的平行方式表达的内容，进行了大量可追溯的科学研究。
仅仅因为它被命名为“令人尴尬”并行并不意味着它不是一个非常重要的领域。
我曾在多家金融机构工作过，我们预计我们可以抛弃1000多台蒙特卡洛发动机（多排叶片排成一排）的农场，用于几个大型NVidia CUDA装置 - 大大降低了电力和热量成本。数据中心。
一个重要的架构优势是网络负载也少得多，因为需要提供数据并报告结果的机器要少得多。
然而，从根本上说，这些技术的抽象级别低于C＃等托管运行时语言，我们讨论的是在自己的处理器上运行自己代码的硬件设备。
首先应该使用Matlab，Mathematica以及C API来完成整合...
答案 3 :(得分：4)
基于GPU处理的另一项技术是现有高级计算库的GPU版本。我知道，它不是很华丽，但它对于便携式代码和编程的简易性具有显着的优势。
例如，AMD的Stream 2.0 SDK包含一个版本的BLAS（线性代数）库，其中一些计算在GPU上实现。 API与他们多年来出货的库的CPU版本完全相同;所需要的只是重新链接应用程序，它使用GPU并运行得更快。
同样，GTRI的Dan Campbell一直在研究用于信号处理的VSIPL标准的CUDA实现。 （特别是在雷达系统和医学成像等相关事物中常见的信号和图像处理。）同样，这是一个标准接口，为其他处理器上的VSIPL实现而编写的应用程序可以简单地用这个重新编译并在适当的时候使用GPU的功能。
在实践中，这些天已经有相当多的高性能数值程序不做自己的低级编程，而是依赖于库。在英特尔硬件上，如果你正在进行数字运算，那么对于它实现的大多数事情来说，通常很难击败英特尔数学库（MKL） - 使用它们意味着你可以获得所有向量指令和更新的x86处理器中的巧妙技巧，无需专门为它们编写代码。对于像GPU这样的东西，我怀疑这会变得更加普遍。
因此，我认为需要关注的技术是开发通用库，这些库构成特定域中应用程序的核心构建块，捕获那些可以有效地发送到GPU同时最小化数量的算法的部分程序员需要的非便携式GPU特定的聪明才智。
（偏见免责声明：我的公司也在开发我们的VSIPL ++库的CUDA端口，所以我倾向于认为这是一个好主意！）
另外，在完全不同的方向上，您可能想要查看RapidMind正在做的一些事情。他们的平台最初用于多核CPU类型系统，但他们也在做一些工作，并将其扩展到GPU计算。
答案 4 :(得分：3)
几乎任何可以并行的东西都可能会受益。更具体的例子是SETI @ home，折叠@ home，以及其他分布式项目以及科学计算。
特别是那些严重依赖浮点运算的东西。这是因为GPU具有专门的电路，在浮点运算中非常快。这意味着它不是那么多才多艺，但它非常擅长它的功能。
如果您想查看更专用的GPU处理，请查看Nvidia's Tesla GPU。它是一个GPU，但它实际上没有监视器输出！
我怀疑我们会在普通桌面上看到太多GPU处理，或者至少有一段时间，因为并非所有人都拥有CUDA或类似功能的显卡，如果他们甚至根本没有显卡。使程序更加平行也很困难。游戏可能会利用这些额外的功能，但这将非常困难，而且可能不会太有用，因为所有图形计算大多已经在GPU上，而其他工作在CPU上，已经由于指令集而在CPU上。
至少在一段时间内，GPU处理将适用于需要大量浮点计算的特定利基市场。
答案 5 :(得分：2)
重要的是要记住，如果必须多次独立执行，即使是本质上串行的任务也可以从并行化中受益。
另外，请记住，每当有人报告GPU实现加速到CPU实现时，几乎从来都不是公平的比较。为了真正公平，实施者必须首先花时间创建一个真正优化的并行CPU实现。如今，单个英特尔酷睿i7 965 XE CPU的双精度可达到70 gigaflops。目前的高端GPU可实现双精度70-80千兆位，单精度1000左右。因此，超过15的加速可能意味着CPU实现效率低下。
GPU计算的一个重要警告是它目前“小规模”。通过超级计算工具，您可以在数百甚至数千个CPU核心上运行并行算法。相比之下，GPU“集群”目前限于连接到一台机器的大约8个GPU。当然，这些机器中的一些可以组合在一起，但这增加了额外的复杂性，因为数据不仅必须在计算机之间传递，而且还要在GPU之间传递。此外，还没有一个MPI等价物允许进程透明地扩展到多台机器上的多个GPU;它必须手动实现（可能与MPI结合使用）。
除了这种规模问题之外，GPU并行计算的另一个主要限制是对存储器访问模式的严格限制。可以进行随机存储器访问，但仔细规划的存储器访问将使性能提高许多倍。
也许最有希望的即将到来的竞争者是英特尔的Larrabee。它可以更好地访问CPU，系统内存，也许最重要的是缓存。这应该给许多算法带来很大的好处。但是，如果它无法与当前GPU上的大容量内存带宽相匹配，那么它可能会落后于最佳使用此带宽的算法的竞争。
当前一代硬件和软件需要大量开发人员才能获得最佳性能。这通常包括重构算法以有效利用GPU内存。它还经常涉及尝试不同的方法来找到最好的方法。
另请注意，获得最佳性能所需的工作量是证明使用GPU硬件的必要条件。天真实现和优化实现之间的差异可以是一个数量级或更多。这意味着优化的CPU故障可能会比天真的GPU实现更好甚至更好。
人们已经在为CUDA开发.NET绑定了。见here。但是，由于需要在低级别工作，我认为GPU计算还没有为大众做好准备。
答案 6 :(得分：1)
我听过很多关于将今天的GPU变成更通用的“阵列处理器单元”的讨论，用于任何矩阵数学问题，而不仅仅是图形处理。虽然我还没有看到太多的东西。
理论上说，阵列处理器可能遵循与浮点处理器几十年前相同的轨迹。最初的浮点处理器是PC的昂贵的附加选项，并没有很多人购买。最终它们变得非常重要，以至于它们被放入CPU本身。
答案 7 :(得分：1)
GPU在Data Level Parallelism级别较高的问题中运行良好，这实际上意味着有一种方法可以对要处理的数据进行分区，以便可以对它们进行处理。
GPU在时钟速度级别上并不具有固有的快速性。事实上，我相对确定着色器上的时钟速度（或者他们现在可能有更多的GPGPU术语？）与现代桌面处理器上的ALU相比，速度相当慢。问题是，GPU拥有绝对数量的这些着色器，将GPU变成一个非常大的SIMD处理器。例如，对于现代Geforce上的着色器数量，GPU可能同时处理数百（上千个）浮点数。
如此简短，GPU可以非常快速地解决您可以正确分区数据并独立处理分区的问题。它在Task (thread) Level Parallelism没有那么强大。
答案 8 :(得分：1)
我会重复我给出的答案here.
长期以来我认为GPU将不复存在，因为通用处理器将逐渐接管这些功能。 Intel's Larrabee是第一步。历史证明，投注x86是一个坏主意。
答案 9 :(得分：1)
GHC（Haskell）研究人员（为Microsoft Research工作）正在将嵌套数据并行技术的支持直接添加到通用编程语言中。这个想法是在后端使用多个内核和/或GPU，但是将数据并行数组暴露为语言中的本机类型，而不管并行执行代码的运行时（或单CPU回退的串行）。 p>
http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell
根据未来几年的成功情况，我希望看到其他语言（特别是C＃）接受这个想法，这可以为更多的主流受众带来这些功能。也许到那个时候CPU-GPU带宽和驱动程序问题将得到解决。
答案 10 :(得分：0)
GPU技术的一个大问题是，虽然你确实拥有很多计算能力，但是将数据输入（和输出）是非常糟糕的（性能方面）。并仔细观察任何比较基准......他们经常将单个处理器系统上的gcc（最小化优化，无矢量化）与GPU进行比较。
GPU的另一个大问题是，如果你没有仔细考虑数据的组织方式，那么你将在内部（在GPU中）遭受真正的性能损失。这通常涉及将非常简单的代码重写为一堆错综复杂的垃圾。
答案 11 :(得分：0)
我对这项技术感到非常兴奋。但是，我认为这只会加剧大型并行任务的真正挑战，即带宽之一。添加更多内核只会增加内存争用。 OpenCL和其他GPGPU抽象库不提供任何改进它的工具。
任何高性能计算硬件平台通常都会设计为在硬件中精心规划带宽问题，平衡吞吐量，延迟，缓存和成本。只要商用硬件，CPU和GPU彼此隔离设计，只为其本地内存优化带宽，就很难为需要它的算法改进这一点。
答案 12 :(得分：0)
正如这里提到的那样，GPU在数据级并行情况下可以实现非常高的性能数字。但正如我所看到的，现在在用户空间中没有多大用处。 我不能不感到所有这些GPGPU宣传都来自GPU制造商，他们只是想为他们的产品寻找新的市场和用途。这绝对没问题。 你有没有想过为什么intel / amd除了标准的内核之外还没有包含一些mini-x86内核（比方说 - 具有四个x86内核和64个mini-x86内核的模型），只是为了提高数据级别的并行性能力？如果需要，他们绝对可以做到这一点。我的猜测是，在普通的桌面/服务器机器中，行业不需要那种处理能力。
答案 13 :(得分：0)
英特尔发布了一款名为Xeon Phi的新加速器，他们希望能够挑战GPU作为HPC加速器。 Cell processor采用了类似的方法，有一个主CPU用于执行常规任务，并将计算密集型任务卸载到其他一些处理元素，实现了一些令人印象深刻的速度。
目前，加速器似乎一直很受关注，因此它们至少应该存在一段时间。 GPU是否仍然是事实上的加速器还有待观察。答案 14 :(得分：-2)
您认为GPU比CPU更快是基于应用于PS3，NVIDIA和ATI硬件的一些令人难以置信的并行应用程序所产生的误解。
http://en.wikipedia.org/wiki/Embarrassingly_parallel
大多数现实世界的挑战都无法轻易分解为这些类型的任务。从功能集和性能角度来看，桌面CPU更适合此类挑战。
答案 15 :(得分：-4)
我希望CPU用于相同的东西？
我只是说这对我来说似乎是个噱头。在技术问题上我毫不犹豫地说“那是无处可去的”，但GPU的主要功能是图形渲染，CPU的主要功能是所有其他处理。让GPU做其他事情似乎很糟糕。