Ste*_*ham 21 parallel-processing cuda gpu opencl
你的CPU可能是四核的,但你知道今天有些显卡有超过200个内核吗？我们已经看到了当今显卡的GPU在图形方面的功能.现在它们也可用于非图形任务,在我看来,结果简直令人惊讶.一种适用于并行性的算法在GPU上可能比在CPU上更快,更快.
有一些技术可以实现所有这些:
1.)NVIDIA的CUDA.它似乎是最知名的,有据可查的.不幸的是,它只适用于NVidia显卡.我已经下载了SDK,尝试了一些样本,并且在CUDA中有一些很棒的东西.但它仅限于NVidia显卡这一事实让我质疑它的未来.
2.)ATI 流.ATI相当于CUDA.正如您所料,它只适用于ATI卡.
3.)OpenCL - Khronos集团已经制定了这个标准,但它仍然处于初期阶段.我喜欢OpenCL的想法.希望它应该得到大多数视频卡制造商的支持,并且应该使交叉视频卡开发变得更加容易.
但是,非图形化GPU编程的其他技术即将到来,最有希望的是什么呢？您是否看到或者您是否希望将这些技术构建到某些主流开发框架(如.NET)中以使其更容易？
chr*_*166 18
我认为你可以将下一个DirectX算作另一种使用GPU的方式.
根据我的经验,GPU对于易于并行化的算法来说非常快.我最近在CUDA中优化了一种特殊的图像大小调整算法,在GPU(甚至不是高端版本)上比四核英特尔处理器快100多倍.问题是将数据传送到GPU,然后将结果提取回主存,这两个方向都受到该机器上memcpy()速度的限制,该速度小于2 GB/s.结果,算法只比CPU版本略快......
所以它真的取决于.如果您有一个科学的应用程序,您可以将大部分数据保存在GPU上,并且所有算法都映射到GPU实现,那么很好.否则我会等到CPU和GPU之间有更快的管道,或者让我们看看ATI的组合芯片是什么......
关于使用哪种技术:我认为一旦你在CUDA中运行你的东西,将它移植到OpenCL(或其他语言)的额外步骤就不那么大了.您通过并行化算法完成了所有繁重的工作,其余的只是一个不同的"味道"
我预见这项技术将成为流行和主流,但这需要一些时间.我的猜测大概是5到10年.
正如您所正确指出的那样,采用该技术的一个主要障碍是缺少在大多数适配器上运行的通用库 - 包括ATI和nVidia.在此问题得到解决之前,该技术将无法进入主流,并将保留在特定硬件上运行的定制应用程序的利基市场.
至于将它与C#和其他高级托管语言集成 - 这将花费更长的时间,但XNA已经证明自定义着色器和托管环境可以在一定程度上混合在一起.当然,着色器代码仍然不在C#中,这样做有几个主要障碍.
快速执行GPU代码的一个主要原因是它对代码可以做什么和不能做什么有严重的限制,它使用VRAM而不是通常的RAM.这使得很难将CPU代码和GPU代码结合在一起.虽然可以采用变通方法,但它们实际上会抵消性能提升.
我看到的一个可能的解决方案是为C#创建一个具有其局限性的子语言,编译为GPU代码,并且具有严格定义的与使用C#代码通信的方式.然而,这与我们已经没有太大的不同 - 由于一些语法糖和标准库函数,编写起来更加舒适.不过,现在这也是很久了.
蒙特卡洛令人尴尬地平行,但它是金融和科学计算的核心技术.
其中一位受访者表示,大多数现实世界的挑战都无法轻易分解为这些类型的任务.
通过利用可以以令人尴尬的平行方式表达的内容来进行大量可追溯的科学调查.
仅仅因为它被命名为"令人尴尬"并行并不意味着它不是一个非常重要的领域.
我曾经在几家金融机构工作,我们预见到我们可以抛弃1000多台蒙特卡洛发动机(多排叶片排成一排)的农场,用于几个大型的NVidia CUDA装置 - 大大降低了数据中心的电力和热量成本.
一个重要的架构优势是网络负载也少得多,因为需要提供数据并报告结果的机器要少得多.
然而,从根本上说,这些技术的抽象级别低于C#等托管运行时语言,我们谈论的是在自己的处理器上运行自己代码的硬件设备.
首先应该使用Matlab,我希望Mathematica,以及C API,当然......