最近我经常读到,由于趋势是构建多核处理器,因此拥有支持并发和并行编程的编程语言将变得越来越重要,以便更好地利用这些处理器提供的并行性(例如,一些背景请参见这段视频 )。
在这方面,某些编程范例或模型被认为非常适合编写健壮的并发软件:
我的问题:
请注意,我要求的不是你的意见或辩论,而是具体的经验或信息。例如,有没有人编写Scala或Haskell程序,用现有的最先进的编译器编译它,以及
总结。到目前为止,制造更快的处理器意味着提高时钟速度,并且不需要改变编程范式。在过去的几年里,制造更快的处理器意味着增加更多的内核,但这要求我们编写不同的软件。我的问题是,软件开发人员是否开始转向新的编程模式,这是否会给多核处理器带来预期的性能提升。
发布于 2012-07-08 02:15:48
(这并不是一个完整的答案,但似乎太长了,不适合发表评论。)
影响软件行业“并行设计”采用率的因素很多。他们中的一些人与福利毫无关系。例如,开发人员的技能集和知识水平等。
我的观察之一是,应用程序的类型决定了它采用并行范式的比率。每个软件产品线(级别)或组件都有一个或多个“自然域/范例”;也就是说,如果软件是在特定范例中实现的,那么开发和维护软件就容易得多。
如果一个范例转换是必要的,以并行化一个特定的应用程序,很可能软件公司不会发现这种成本效益的理由。如果这个特定的范例很容易并行化,那么您看到的是,这些软件对于并行编程具有更高的采用率。
关于范例列表,我想添加一下Dataflow。所有的任务都是预先宣布的。每个任务在执行前都声明其输入和输出。一旦任务的所有输入数据都可用,就会启动该任务。
Dataflow范例:
答1:
仅仅有一个非常成功的范例是不够的。为了提高并行编程的采用率,还需要将并行性引入到其他范式(包括“过时的”范式)中。
我见过其他人在Windows GUI程序中成功地实现了并行性,他们在每个计算任务中生成一个Windows对话框(每个Windows对话框都位于一个线程中),并使用Windows消息交换数据。
回答2:
这与我上面的观察相呼应:如果将并行性引入到应用程序中需要以非自然的范式重写应用程序,那么开发和维护的复杂性就会增加。
回答3:
对于纯粹的计算密集型任务,性能增益通常与Amdahl定律的预测非常接近,前提是所有的计算都是在本地完成的(即不受网络I/O流量慢得多的影响)。
尽管如此,您将很快发现应用程序中存在不可并行的瓶颈。有时这些瓶颈在理论上是不可并行的,这意味着没有希望找到更好的算法。
回答4:
一个私人故事。我编写了一个简单的并行化程序来解码JPEG文件,调整它的大小,然后将它保存为自定义的图像文件格式。在测试时,我发现当使用3个线程或4个线程进行测试时,程序需要1.6秒才能完成。事实证明,JPEG解码步骤占用了超过25%的时间,这使得它成为最慢的不可并行的步骤。
换句话说,Amdahl定律对我的小程序来说只有3-4个CPU核就生效了。
有时,如果允许您更改软件需求(例如,如果您可以要求客户不使用特定的图像格式),这些瓶颈就可以消除,但大多数情况下,需求是固定的。
发布于 2012-07-08 09:44:32
您无法神奇地使不为并发性编写的代码同时正常工作(并且神奇地包括使用编译器)。
很多时候,条件已经改变,代码需要进行不同的操作。在过去的日子里,记忆是一种宝贵的东西,所以自修改代码是很常见的。如今,内存中的代码被只读的好处如此之大,以至于所有现代操作系统都想要执行它。
同时,想想Windows流行时发生了什么。所有DOS程序员都不得不重新考虑他们的编程方式。您不能让一个键盘轮询循环调用单个线程程序中的完整应用程序功能--您必须拥有事件处理程序--这反过来又改变了应用程序代码的设计方式。
像“使用不变的对象!”这样的咒语!经验是很难学到的。原因是为什么经常迷失在途中,但可以重建。“使用不可变对象”是一种简单的方法,它允许缓存多个位置,而不需要将程序中断到这些位置之一进行更新。
需要并发的更改不需要用函数式语言进行完全重写,而是可以用库来解决--这允许保留现有的代码库--但是您仍然需要编写程序才能使用它。OpenCL (Grand Central in OS )方法是一种非常有趣的方法,可以同时使用CPU和GPU来执行代码,但是您也需要相应地编写程序。
在Java中,我们花费了大量的精力来提供良好的构建块,以透明地扩展小代码段的执行,但是如果不为其编写代码段,则不能使用它。
https://softwareengineering.stackexchange.com/questions/155980
复制相似问题