作为来自企业Web开发世界的HPC世界中的某个人,我总是很想知道回到"现实世界"的开发人员如何利用并行计算.现在所有芯片都在进行多核处理,这就更加重要了,当芯片上有数千个内核而不是少数内核时,它会更加相关.
我的问题是:
这对您的软件路线图有何影响？
我对关于多核如何影响不同软件领域的真实故事特别感兴趣,因此请说明您在答案中做了哪种开发(例如服务器端,客户端应用程序,科学计算等).
您正在使用现有代码来利用多核计算机,以及您面临的挑战是什么？您使用的是OpenMP,Erlang,Haskell,CUDA,TBB,UPC还是其他什么？
当并发级别继续增加时,您打算做什么？您将如何处理数百或数千个内核？
如果您的域名不容易从并行计算中受益,然后解释为什么是有趣的.
最后,我将此视为一个多核问题,但随意谈论其他类型的并行计算.如果您正在移植部分应用程序以使用MapReduce,或者如果大型集群上的MPI是您的范例,那么也要明确提及.
更新:如果您回答#5,请提及您是否认为如果有更多内核(100,1000等)可以改变,而不是可以提供可用内存带宽(看看每个内核带宽越来越小) ).您是否仍可以将剩余的核心用于您的应用程序？
我的研究工作包括编译器和垃圾邮件过滤方面的工作.我也做了很多'个人生产力'的Unix东西.另外,我编写和使用软件来管理我教授的课程,包括评分,测试学生代码,跟踪成绩和无数其他琐事.
除了作为编译器支持其他应用程序的研究问题之外,多核对我一无所知.但是那些问题主要在于运行时系统,而不是编译器.
由于麻烦和费用,Dave Wortman在1990年左右展示了你可以并行编译器以保持四个处理器忙碌.我认识的任何人都没有重复这个实验. 大多数编译器都足够快,可以运行单线程.并行运行顺序编译器在几个不同的源文件上比在编译器本身并行上容易得多.对于垃圾邮件过滤,学习是一个固有的顺序过程.即使是较旧的机器也可以每秒学习数百条消息,因此即使是大型语料库也可以在一分钟内学会.再次,培训足够快.
我利用并行机器的唯一重要方法是使用并行make.这是一个很好的福音,大型构建很容易并行化.Make会自动完成所有工作.我记得的唯一另一件事就是使用并行性来计算长时间运行的学生代码,将其分配给一堆实验室机器,我可以很好地做到这一点,因为我每台机器只打破一个核心,所以只使用1/4个CPU资源.哦,我写了一个Lua脚本,在使用lame翻录MP3文件时将使用所有4个核心.这个脚本是很多工作要做对的.
我将忽略数十,数百和数千个核心.我第一次被告知"并行机器即将到来;你必须做好准备"是1984年.当时并非如此,并行编程是高技能专家的领域.唯一改变的是,无论我们是否愿意,今天的制造商都在迫使我们支付并行硬件的费用.但仅仅因为硬件付费并不意味着它可以免费使用. 编程模型很糟糕,并使线程/互斥模型工作即使硬件是免费的,更不用说表现良好,也是一项昂贵的工作.我希望大多数程序员忽略并行性并悄悄地继续他们的业务.当熟练的专家带来并行制作或精彩的电脑游戏时,我会默默地鼓掌并利用他们的努力.如果我想为自己的应用程序提供性能,我将专注于减少内存分配并忽略并行性.
并行性真的很难. 大多数域很难并行化.一个广泛可重用的例外,如并行make,是令人高兴的原因.
总结(我从一位为一家领先的CPU制造商工作的主题发言人那里听到):业界支持多核,因为他们无法让机器运行得更快更热,而且他们不知道如何处理额外的晶体管.现在他们迫切希望找到一种方法来使多核盈利,因为如果他们没有利润,他们就无法建立下一代的生产线.肉汁火车已经结束,我们可能实际上必须开始关注软件成本.
许多认真对待并行性的人忽略了这些玩具4核甚至32核的机器,转而使用128个或更多处理器的GPU.我的猜测是真正的行动将在那里.
对于Web应用程序,它非常非常容易:忽略它.除非你有一些真正需要并行完成的代码,否则你只需编写旧式的单线程代码就可以了.
在任何给定时刻,您通常都会有比处理核心更多的请求.而且由于每个都是在自己的线程中处理(甚至是处理,取决于你的技术),这已经在并行工作.
您需要注意的唯一地方是访问需要同步的某种全局状态.将其保持在最低限度,以避免将人为瓶颈引入其他(几乎)完全可扩展的世界.
所以对我来说,多核心基本归结为这些项目:
我的服务器拥有较少的"CPU",而每个服务器都运行更多核心(对我来说没什么区别)
相同数量的CPU可以占用更多的并发用户
当似乎是性能瓶颈而不是 CPU 100%加载的结果时,那表明我在某处做了一些糟糕的同步.
目前 - 说实话并不会影响那么多.我更多地处于"准备阶段",了解使这成为可能的技术和语言功能.
我没有一个特定的域名,但我遇到过像数学这样的域名(其中多核心是必不可少的),数据排序/搜索(多核心上的分而治之有用)和多计算机要求(例如,一个备用站的处理能力的要求是使用的东西).
这取决于我正在使用的语言.显然在C#中,我的手与尚未准备好的并行扩展实现相关联,这似乎可以提高性能,直到您开始将相同的算法与OpenMP进行比较(可能不是公平的比较).所以在.NET上,使用一些for→ Parallel.For重构等就可以轻松实现.
事情变得非常有趣的是C++,因为与.NET相比,你可以挤出OpenMP这样的性能是惊人的.事实上,OpenMP让我感到很惊讶,因为我没想到它会如此高效地工作.好吧,我猜它的开发人员有很多时间来改进它.我也喜欢它可以在开箱即用的Visual Studio中使用,不像您需要付费的TBB.
至于MPI,我使用PureMPI.net进行小型家庭项目(我有一个局域网)来愚弄一台机器无法完成的计算.我从来没有在商业上使用过MPI,但我知道MKL有一些MPI优化的功能,对于需要它们的人来说,这可能很有意思.
我计划进行'轻浮计算',即使用额外的内核来预先计算可能需要或可能不需要的结果 - 当然RAM允许.我还打算深入研究大多数最终用户的机器现在无法处理的昂贵的算法和方法.
对于不受并行化影响的领域......好吧,总能找到一些东西.有一两件事我很关心的是在.NET体面的支持,但遗憾的是我已经放弃希望,速度类似于C++可以实现.
我从事医学成像和图像处理工作.
我们处理多个内核的方式与处理单个内核的方式大致相同 - 我们在编写的应用程序中已经有多个线程,以便拥有响应式UI.
但是,因为我们现在可以,我们正在强烈关注在CUDA或OpenMP中实现大多数图像处理操作.英特尔编译器为OpenMP提供了许多优秀的示例代码,并且只是比CUDA更成熟的产品,并提供了更大的安装基础,因此我们可能会采用这种方式.
如果可以的话,我们倾向于为昂贵的(即超过一秒的)操作做的事情是将该操作分成另一个进程.这样,主UI仍然保持响应.如果我们不能,或者移动那么多内存太不方便或太慢,那么操作仍然在一个线程中,然后该操作本身可以产生多个线程.
我们的关键是确保我们不会遇到并发瓶颈.我们在.NET中开发,这意味着必须通过对UI的Invoke调用来完成UI更新,以便让主线程更新UI.
也许我很懒,但实际上,我不想花太多时间来解决很多这样的问题,比如矩阵反转之类的东西.许多非常聪明的人花了很多时间像亚硝酸盐一样快速制作这些东西,我只是想把他们所做的事情称之为.像CUDA这样的东西有一个有趣的图像处理界面(当然,这就是它的定义),但对于那种即插即用的编程来说仍然太不成熟.如果我或其他开发人员获得了大量的业余时间,我们可能会尝试一下.因此,我们将使用OpenMP来加快处理速度(这绝对是未来几个月的开发路线图).
我正在开发ASP.NET Web应用程序.在我的代码中直接使用多核的可能性很小,但是IIS在加载时通过产生多个工作线程/进程已经很好地扩展了多个内核/ CPU.
到目前为止,只有更有效的编译make:
gmake -j
该-j选项允许不依赖于彼此的任务并行运行.
我们在使用F#的.NET 4中的任务并行性方面取得了很大的成功.我们的客户迫切希望获得多核支持,因为他们不希望他们的n-1核心闲置!
京公网安备 11010802040832号 | 京ICP备19059560号-6 