你的CPU可能是四核，但你可知道，一些图形卡今天有超过200个核心？ 我们已经看到，当涉及到图形能做什么GPU在当今的显卡。 现在，他们可以用于非图形任务，以及，在我看来，结果是令人惊叹。 这本身很适合并行算法有多大，更快的在GPU上比它可能永远不会在CPU上的潜力。
有一些技术，使这一切成为可能：
1.） CUDA由NVIDIA。 这似乎是最知名的和良好的记录。 不幸的是，它只会在NVIDIA显卡的工作。 我已经下载了SDK，尝试了一些样品，并有该公司在CUDA正在做一些真棒的东西。 但事实上，这是仅限于NVidia显卡让我质疑它的未来。
2.） 流由ATI。 ATI的相当于CUDA。 正如你所期望的，它只能在ATI显卡工作。
3） 的OpenCL - Khronos组织已经把这个标准，但它仍然处于起步阶段阶段。 我喜欢的OpenCL的想法虽然。 希望的是，它应该被大多数显卡厂商的支持，并应进行跨视频卡开发容易得多。
但是其他技术的非图形GPU编程来了，显示的内容最有前途？ 而且你看，或者你希望看到这些技术被内置到一些主流的开发框架.NET一样，使其更加容易？
我预计，这一技术将会成为流行和主流，但它需要一定的时间来做到这一点。 我的猜测是约5至10年。
当你正确地指出，对于采用该技术的一个主要障碍是缺乏对大多数适配器运行的公共库的 - 无论是ATI和nVidia。 在此之前解决到可接受的程度，技术不会进入主流，并会留在那个特定的硬件上运行的定制应用程序的利基。
至于C＃和其他高级管理语言集成起来 - 这将需要更长的时间，但XNA已经证明了自定义着色器和管理环境，可以混合在一起 - 在一定程度上。 当然，shader代码仍然没有在C＃中，有这样做的几个主要障碍。
其中一个主要的原因的GPU代码执行速度快是它有什么代码可以和不可以做严格的限制，而且它使用的，而不是通常的RAM显存。 这使得它难以带来一起CPU代码和GPU代码。 而解决方法是可能的，他们将几乎否定的性能增益。
一个可能的解决方案，我看到的是做一个子语言有其局限性，编译成GPU代码C＃，并有严格的定义与ususal C＃代码的沟通方式。 然而，这并不比我们已经太大不同 - 只是更舒服，因为一些语法糖和标准库函数来写。 不过，这也就是离开现在的年龄。
我想你可以算下的DirectX作为另一种方式来使用GPU。
从我的经验，GPU是对于易于并行算法的速度极快。 最近，我优化的特殊图像中的CUDA调整大小算法要快100倍以上在GPU上（即使不是高端的一个）比四核英特尔处理器。 该问题是在数据获取到GPU，然后取结果回主存储器，两个方向上由该机器，这是小于2 GB / s的上的memcpy（）速度的限制。 其结果是，该算法只比CPU版本稍快...
因此，它实际上取决于。 如果你有一个科学的应用程序，你可以保留大部分数据在GPU上，和所有的算法映射到GPU执行，然后罚款。 否则我会等到有CPU和GPU之间更快的管道，还是让我们来看看ATI有他们的袖子与组合芯片...
关于使用哪种技术：我认为一旦你有你的东西在CUDA，其它步骤将它移植到OpenCL的（或其他语言），运行的是没有那么大。 你做了所有的重活通过并行算法的，剩下的仅仅是一个不同的“味道”
蒙特卡洛是尴尬的并行，但它是在金融和科学计算的核心技术。
一位受访稍微不正确地说，大多数现实世界的挑战是不容易分解到这些类型的任务。
许多tractible科学考察是通过利用什么可以在一个尴尬的并行的方式来表达实现。
只是因为它被命名为“尴尬”并行并不意味着它不是一个非常重要的领域。
我在几个的金融机构工作过，我们预见，我们可以扔掉1000+蒙特卡洛引擎（叶片排列在一起的许多栈）为几个大的NVIDIA CUDA设施的养殖场 - 大量减少数据中心的电力和散热成本。
一个显著架构的好处是，有少了很多网络负载也因为有这需要美联储的数据和报告其成果远不如机器。
从根本上说然而，这种技术是在抽象的水平比管理运行系统语言较低，如C＃中，我们谈论的是对自己的处理器上运行他们自己的代码的硬件设备。
整合应先用Matlab，数学做我预计，随着课程的C-的API一起...
这是未来基于GPU的处理另一种技术是现有的高级别计算库GPU版本。 不是很华丽，我知道，但它具有可移植的代码和易于编程的显著优势。
例如，AMD的流2.0 SDK包括：使用一些在GPU上执行的计算的一个版本其BLAS（线性代数）库。 API是完全一样的CPU的唯一版本，他们已经运好多年的库; 所有需要被重新链接的应用程序，它采用了GPU和运行速度更快。
同样，丹·坎贝尔在GTRI一直在CUDA实现信号处理的VSIPL标准。 （具体地，排序信号和图像处理，在雷达系统和相关的东西等医学成像很常见的。）再一次，这是一个标准接口，并已用在其它处理器VSIPL实施方式编写的应用程序可以简单地与这一个重新编译并在适当情况下使用GPU的能力。
在实践中，这些天已经不少高性能的数值方案不做自己的低级编程，但依靠库。 在英特尔硬件，如果你正在做数字运算，它通常很难被击败的，它实现了大部分的东西英特尔数学库（MKL） - 并利用它们意味着你可以得到所有的向量指令的优势，聪明的技巧在新的x86处理器，而无需专门的代码为他们。 随着之类的东西的GPU，我怀疑这会变得更加普遍。
所以我觉得看一个技术是形成在特定领域应用的核心构件的通用库，在如何发展是的，可以同时最大限度地减少非便携GPU的量有效地被红牌罚下GPU的这些算法捕捉部分从编程所需的特异性聪明。
（偏置免责声明：我公司也一直是我们VSIPL ++库的CUDA端口上的工作，所以我倾向于认为这是一个好主意）
此外，在一个完全不同的方向，你可能想看看一些的那个是RapidMind正在做的事情。 他们的平台最初是打算用于多核CPU类型的系统，但他们一直在做工作的一个好一点的它，以及延伸到GPU计算。
几乎任何可以并联也许能够受益。 更具体的例子是SETI @ home的，Folding @ Home的，和其他分布式项目以及科学计算。
特别的东西，在很大程度上依赖于浮点运算。 这是因为GPU的有专门的电路，这是非常快的，在浮点运算。 这意味着它不是通用的，但它是在什么它做的非常好。
如果你想看看更多的专用GPU处理，检查了Nvidia的GPU的Tesla 。 这是一个GPU，但它实际上并没有一个监视器输出！
我怀疑我们将看到太多的GPU处理常见的桌面上，或者至少一会儿，因为不是每个人都有一个CUDA或类似的图形卡，如果他们甚至有一个显卡都没有。 这也很难使程序更加并行。 游戏可能可能利用这一额外的动力，但是这将是非常困难的，可能不会有太大的用处，因为所有的图形计算大多是已经在GPU和其他工作是在CPU上，并有可能成为CPU上，由于该指令集。
GPU处理，至少在一段时间，将是那些需要大量浮点运算的非常具体的利基市场。
重要的是要记住，即使任务，这本身就可以连续从并行化中受益，如果他们必须独立进行许多次非常重要的。
此外，记住，每当有人报告了GPU实现的CPU执行的加速，这是几乎从来没有一个公平的比较。 为了实现真正的公平，实施者必须先花打造一个真正的优化，并行CPU执行时间。 一个单一的英特尔酷睿i7 965 XE CPU能取得今天的双精度约为70亿次。 目前高端的GPU可以做双精度和1000年左右在单精度70-80亿次。 因此超过15的加速可能意味着低效率的CPU实现。
与GPU计算的一个重要警告是，它是目前“小规模”。 随着超级计算设施，您可以运行数百甚至数千个CPU内核的并行算法。 与此相反，GPU“集群”目前只限于连接到一个机器约8的GPU。 当然，一些这些机器可以结合在一起，但是这增加了额外的复杂性，因为数据必须不仅电脑之间，而且GPU之间传递。 另外，现在还没有一个MPI相当于让过程透明地扩展到多台机器上多个GPU; 它必须手动执行（可能结合MPI）。
除了规模的这个问题，GPU的并行计算的另一主要限制是对存储器的访问模式的严重限制。 随机内存访问是可能的，但精心策划的内存访问将会导致很多倍的性能更好。
也许最有希望即将到来的竞争者是Intel的Larrabee的。 它的CPU，系统内存，并且，也许要好得多访问最重要的是，高速缓存。 这应该有很多算法给它相当大的优势。 如果它不能在目前的GPU海量内存带宽相匹配，但是，它可能是竞争为最佳使用带宽算法背后的滞后。
目前这一代的硬件和软件需要大量的开发努力，获得最佳的性能。 这通常包括调整算法，有效地利用GPU内存。 它也经常涉及到不同的方法进行试验，以找到最好的之一。
还需要注意的是，以获得最佳性能所需要的努力是必要的，以证明使用GPU硬件。 幼稚实现和优化的执行之间的差异可以是数量级或更多的顺序。 这意味着，一个优化的CPU impelemntation很可能会一样好，甚至天真的GPU实现甚至更好。
人们已经着手对CUDA .NET绑定。 见这里 。 然而，在低级别工作的必要性，我不认为GPU计算已经准备好为群众呢。
我听到的谈话大量有关打开今天是GPU的成更通用的“阵列proceesor单位”，与任何矩阵数学题使用，而不仅仅是图形处理。 我没见过什么来它尚未虽然。
该理论认为，阵列处理器可以大致遵循同样的轨迹浮点处理器跟着几十年之前。 本来浮点处理器是昂贵的附加选项PC的，不是很多人不屑于买。 最终，他们变得如此重要，他们投入的CPU本身。
我再重复一次我给的答案在这里。
长期我认为，GPU将不复存在，作为通用处理器发展到接管这些功能。 英特尔的Larrabee是第一步。 历史已经证明，对赌的x86是一个坏主意。
GHC（哈斯克尔）的研究人员（工作微软研究院）直接增加了对嵌套数据并行支持的通用编程语言。 该想法是使用多个内核和/或GPU在后端尚未暴露数据平行阵列作为语言本机类型，而不管执行（用于单CPU回退或串行）并联的代码的运行时。
http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell
根据这个，在未来几年取得的成就，我希望看到其他语言（C＃专）拿起的想法，这可能使这些各种各样的功能，更主流的观众。 也许到那时的CPU-GPU带宽和驱动程序问题将得到解决。
的GPU中的问题很好地工作，其中有一个高层次的数据级并行性 ，这本质上意味着有一种方法来划分要处理的数据，使得它们可以全部被处理。
GPU是不是天生的速度在时钟速度水平。 其实我是比较肯定的着色器时钟速度（或者也许他们有他们这些天？更GPGPU的术语）相比，ALU的一个现代化的台式机处理器是相当缓慢。 问题是，一个GPU有这些着色器的绝对量很大，转动GPU到一个非常大的SIMD处理器。 随着着色器的一个现代的Geforce量，例如，有可能为几百个可正常工作的GPU（千？）的浮点数一次。
所以，简单地说，GPU可以惊人的快的问题，在这里你可以适当地将数据划分和独立处理的分区。 这不是那么强大的任务（线程）级并行 。
随着GPU技术的一个大问题是，当你确实有很多计算能力在那里，将数据传输到（和出它）是可怕的（性能明智）。 并仔细观看任何比较基准......他们往往比较GCC（以最少的优化，没有量化）单处理器系统到GPU上。
与GPU的另一个大问题是，如果你不仔细想想你的数据是如何组织的，你将遭受打击内部（在GPU）一个真正的性能。 这往往涉及到重写非常简单的代码到垃圾的一个令人费解的一堆。
我对这项技术感到非常兴奋。 但是，我认为，这只会加剧的大规模并行任务，带宽的一个真正的挑战。 增加更多的内核只会增加争用内存。 OpenCL和其他GPGPU抽象库不提供任何工具来改善这一点。
任何高性能计算硬件平台通常被设计为与带宽问题，精心策划，到硬件，平衡吞吐量，延迟，缓存和成本。 只要商品硬件，CPU和GPU的，被设计在彼此隔离，优化带宽只有到他们的本地内存，这将是非常难以提高这个对于需要它的算法。
它真的能的GPU实现数据级并行的情况非常喜性能数据，为许多这里提到。 但在我看来，没有多大用处它在用户空间了。 我不能说这一切GPGPU宣传来自GPU制造商，它只是想找到新的市场，并使用他们的产品帮助的感觉。 并且那absolutelly确定。 你有没有想过，为什么英特尔/ AMD didnt包括除了标准的人一些小型x86核心（可以说 - 模型有四个x86核心和64只小86核），只是为了增强数据级paralelism capabilties？ 他们肯定能做到这一点，如果想要的。 我的猜测是，业界只是不需要那种在常规的桌面/服务器计算机的处理能力。
GPU可像现在或可能仍然不那么受欢迎，但其基本思想正在成为一种相当流行的方法，以高功率处理。 现在快到了一种趋势是外部“加速器”大型浮点运算工作来帮助CPU。 GPU的只是一种类型的加速器。
英特尔还发布了一个名为新的加速器至强融核 ，其中他们希望能够挑战GPU作为加速器HPC。 该Cell处理器也采取了类似的做法，有做普通任务，并卸载计算密集型任务的一些其他处理元件，实现了一些令人印象深刻的速度一个主CPU。
一般加速器似乎是在目前的利益，所以他们至少应该有一段时间了。 无论是否GPU仍然作为事实上的加速器，还有待观察。
您的看法，即GPU是比CPU快是基于应用到PS3，NVIDIA和ATI硬件喜欢的几个embarassingly并行应用程序创建的误解。
http://en.wikipedia.org/wiki/Embarrassingly_parallel
大多数现实世界的挑战是不容易分解到这些类型的任务。 桌面CPU是更好的方式适用于无论从功能集和性能的角度来看这种类型的挑战。
我想到的是CPU的用于同样的事情？
我只是说这似乎是一个噱头给我。 我毫不犹豫地说“这是无处可去”，当涉及到的技术，但GPU的主要功能是图形渲染和CPU的主要功能是所有其他处理。 具有GPU做任何事情似乎只是怪诞。
