{技术}{多线程}实施并行编程的五大障碍

419 views
Skip to first unread message

Guancheng Chen

unread,
Mar 21, 2010, 7:37:49 PM3/21/10
to TopLanguage
近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问“什么是实施并行编程的最大障
碍”时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
(fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
的看法。

( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看
http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-parallelism/
)

1. 遗留代码
众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
一大堆诸如data race, dependency, non-deterministic, memory consistency,
dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
没有dependence,并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化,从商业的角度上来讲,如果能
有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码获得10%~30%的性能提升,那么它就已经能为公司节省大量成本了。

2. 教育
第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史了,不过在多核CPU出现之前那些并行编程都是“专家”们的玩
具。那时候的并行编程大都是跑在集群、大型机或者服务器上,通过MPI(message passing model)或者SMP(对称多处理器,即一
个主板上有多个单核CPU,属于shared memory model)来完成并行计算。Pthread标准是1995年建立的,之后出来了
Windows版的Win32 thread,后来又出来了“编译指导”、面向data parallel模型的OpenMP(OpenMP 3.0加
入了task parallel支持),task parallel的鼻祖Click,Intel的Intel Thread Building
Block(task parallel),Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model),近几年随着
GPU的发展,Nvidia又开始搞CUDA(data-parallel),Apple一看不对,并行编程以后是主流啊,我得插一手,于是自己撑旗弄
了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也
要加入多线程支持,甚至连老古董Erlang也因为天生支持并行被重新热炒,总之随着摩尔定律在串行世界的失效,整个业界都开始被迫往并行编程方向发
展。

可是对程序员来说呢是什么情况呢?我们现在所接受的教育大都还是串行世界的那些算法和数据结构,高德纳在一篇访谈里说“在我看来,这种现象或多或少是由
于硬件设计者已经无计可施了导致的,他们将Moore定律失效的责任推脱给软件开发者,而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线
程的想法被证明是失败的,我一点都不会感到惊讶……你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣?我几乎没有听说过,除了他们的诉苦。
尽管我们学院那些搞硬件的家伙一直想让我相信我是错的”,可见硬件发展被迫向多核转移直接导致程序员们免费的午餐已经结束了。那么程序员现在受到良好的
并行编程教育了吗?很显然,现在随便问一个普通的程序员:“你觉得并行编程容易么?”,十有八九会说“我觉得很难”。前一阵有人讨论服务器编程用多线程
好还是多进程好?其实根本原因就在于哪怕多线程有性能优势,可是isolation的多进程模式能在programming productivity
和performance之间找到比较好的折衷,所以国内很有服务器开发者都选择了多进程(例如云风)。从大趋势上来讲,不管是研究体系机构的,还是写
OS/Compiler的,还是定义编程语言的,现在都在积极努力的为广大的程序员提供一个更容易使用的并行编程模型,Intel这几年不也在搞多核培
训么,这都是好现象,但是,离真正的全民并行编程时代还有相当长的路要走。近几年的IT技术热门书单里面很少有并行编程的书籍就是个很好的写照。

3. 工具
工欲善其事,必先利其器。那么现阶段我们能用的,并且好用的并行编程工具有多少呢(欢迎大家补充)?

(1) IDE: Intel Parallel Studio,微软马上出来的VS2010算一个,Sun的Sun Studio(不知道它的未来如
何,但是它本来就很小众),Nvidia的CUDA平台什么的就先不算了
(2) Compiler: Intel的ICC(能自动并行化一些代码),Nema Labs的FASThread(针对遗留代码的解决方案,能快速
可靠的指导程序员实施并行化)
(3) Performance Tuning: Intel Vtune Analyzer(综合性能分析),Thread profiler,
Acumem的Thread Spotter(针对多核Cache的性能分析和优化)
(4) Debugging: Petra的Jinx

总体上我个人觉得它们对程序员来说确实有用,但是前提条件是你要会用。这其实又跟第二点“教育”有很大关系了。

4. 对众核的恐惧
现在我们看到4核已经非常普遍了,等过几年那可就是8核,16核,32核了。怎样确保你的代码在核数倍增的趋势下仍能有很好的性能,很好的可伸缩性?这
真的是个问题。我现在所做的研究就是多线程程序中锁竞争的性能分析,目的就是为了帮助程序员更好的解决由锁竞争造成的性能瓶颈。实际上,为了得到很好的
可伸缩性,程序员需要往往需要使用并行友好的数据结构(例如concurrent hash map),使用细粒度的锁甚至无锁编程,设计data
parallel的算法,性能调优(例如典型的false sharing问题)等等等等,这其中每一项都是不小的挑战。我曾经翻译过的一篇文章对设计
多线程程序提供了一些有用的建议。

5. 可维护性
毫无疑问,我们希望并行代码能够与现存的runtime系统、build系统以及其他现有代码一起正确的工作,我们更希望这些并行代码易于理解、便于维
护并且有较长的生命周期。可是现阶段真正掌握并行编程的程序员少之又少,而且并行编程又是这么困难,哪怕你对这些并行代码只是做一些小小的改动都很有可
能导致新的bug,新的性能瓶颈,那真的是一件非常痛苦的事情。

机械唯物主义 : linjunhalida

unread,
Mar 21, 2010, 7:42:07 PM3/21/10
to pon...@googlegroups.com
恩恩,有些事情还是没有并行的必要。等光处理器出来就好了。

2010/3/22 Guancheng Chen <chengu...@gmail.com>
To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

陨落雕

unread,
Mar 21, 2010, 8:46:44 PM3/21/10
to TopLanguage
呃,我想的障碍是: 1. 类C语言的统治地位; 2. 内存带宽不够; 3. 误导性宣传;

On Mar 21, 7:37 pm, Guancheng Chen <chenguanch...@gmail.com> wrote:
> 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> 的看法。
>

> ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...


> )
>
> 1. 遗留代码
> 众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
> 一大堆诸如data race, dependency, non-deterministic, memory consistency,
> dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
> 效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
> 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
> 能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
> 没有dependence,并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化,从商业的角度上来讲,如果能
> 有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码获得10%~30%的性能提升,那么它就已经能为公司节省大量成本了。
>
> 2. 教育
> 第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史了,不过在多核CPU出现之前那些并行编程都是"专家"们的玩
> 具。那时候的并行编程大都是跑在集群、大型机或者服务器上,通过MPI(message passing model)或者SMP(对称多处理器,即一
> 个主板上有多个单核CPU,属于shared memory model)来完成并行计算。Pthread标准是1995年建立的,之后出来了
> Windows版的Win32 thread,后来又出来了"编译指导"、面向data parallel模型的OpenMP(OpenMP 3.0加
> 入了task parallel支持),task parallel的鼻祖Click,Intel的Intel Thread Building
> Block(task parallel),Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model),近几年随着
> GPU的发展,Nvidia又开始搞CUDA(data-parallel),Apple一看不对,并行编程以后是主流啊,我得插一手,于是自己撑旗弄
> 了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也
> 要加入多线程支持,甚至连老古董Erlang也因为天生支持并行被重新热炒,总之随着摩尔定律在串行世界的失效,整个业界都开始被迫往并行编程方向发
> 展。
>
> 可是对程序员来说呢是什么情况呢?我们现在所接受的教育大都还是串行世界的那些算法和数据结构,高德纳在一篇访谈里说"在我看来,这种现象或多或少是由
> 于硬件设计者已经无计可施了导致的,他们将Moore定律失效的责任推脱给软件开发者,而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线

> 程的想法被证明是失败的,我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣?我几乎没有听说过,除了他们的诉苦。

Guancheng Chen

unread,
Mar 21, 2010, 8:55:15 PM3/21/10
to TopLanguage
可是按现在的趋势,多核一定会在光处理器之前成为主流啊

On 3月22日, 上午12时42分, 机械唯物主义 : linjunhalida <linjunhal...@gmail.com>
wrote:
> 恩恩,有些事情还是没有并行的必要。等光处理器出来就好了。
>
> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>


>
>
>
> > 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问“什么是实施并行编程的最大障
> > 碍”时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> > (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> > Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> > 的看法。
>
> > ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看
>

> >http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...

Guancheng Chen

unread,
Mar 21, 2010, 8:58:37 PM3/21/10
to TopLanguage
1. C语言可以使用pthread等库实现并行化,C++ JAVA等已经会即将支持多线程 所以语言能实现并行化 只是难易问题
2. 是指Shared memory模型,多核共享一条内存总线所以造成带宽问题么?这确实是个问题,不过我感觉硬件商家会负责为你带来越来越多的带
宽,而程序员的任务只是合理的利用好这些给定的带宽
3. 能具体说说哪些误导宣传么?

Jeffrey Zhao

unread,
Mar 21, 2010, 9:15:01 PM3/21/10
to TopLanguage
我来做广告:有了并行库、或是F#这种语言的支持,并行编程已经容易很多了。开发效率,执行效率,可维护性都可以有显著提高。
 
其实还是“抽象”这个万能武器的作用,只要有牛人把容易出问题的东西隐藏起来,封装起来,给一个好用的抽象,对大部分程序员来说就能美好许多。
 
例如Memory Consistency,让JVM或CLR那样在各CPU架构中统一起来,即便是没有并行库的支持,写并行程序已经可以轻松很多了。
 
至于教育上……我觉得其实这个问题倒不是并行特有的,也不是并行上面表现的更彻底,而是(国内)本来就没多少人被教育好。
 
例如计算机体系结构,操作系统等等。这虽然和并行有关,但也不是并行特有的东西。
 
To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Tinyfool

unread,
Mar 21, 2010, 9:20:59 PM3/21/10
to pon...@googlegroups.com
唉,本来不想广告的,既然赵姐夫都冒出来了,我也来广告一下

Mac OS X最新的并行机制叫做GCD,靠,听名字就知道无比强大了吧?

还有支持显卡计算的OpenCL也是无比强大啊。

2010/3/22 Jeffrey Zhao <je...@live.com>



--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool

陨落雕

unread,
Mar 21, 2010, 9:25:57 PM3/21/10
to TopLanguage
1. 这和第二个问题是连起来的,到最后,你还是操作的mutable object,就是无穷无尽的memory consistency的麻烦;
2. 就是这个问题,可惜从来都没跟上来过,光传输是一个可行性,如果实现了的确会改变现在的处境;
3. 说在shared memory模型上内核数量可以无限上去的误导宣传,可惜这个20年前就失败,现在在TOP500上能看到的
supercomputer都是distributed memory model;

陨落雕

unread,
Mar 21, 2010, 9:33:40 PM3/21/10
to TopLanguage
OpenCL解决了一大类的问题(每个kernel只需要一小部分数据,类似rasterization的渲染),而且现在他们有动力解决另一大类的问
题(每个小的kernel需要查询大量数据,类似ray tracer的渲染)。但是现在移植还是好困难啊,特别是显存和内存通信时候的
consolation,头疼死了,显存不够要swap out的时候,也很头疼。

On Mar 21, 9:20 pm, Tinyfool <tinyf...@gmail.com> wrote:
> 唉,本来不想广告的,既然赵姐夫都冒出来了,我也来广告一下
>
> Mac OS X最新的并行机制叫做GCD,靠,听名字就知道无比强大了吧?
>
> 还有支持显卡计算的OpenCL也是无比强大啊。
>
> 2010/3/22 Jeffrey Zhao <je...@live.com>
>
>
>
> > 我来做广告:有了并行库、或是F#这种语言的支持,并行编程已经容易很多了。开发效率,执行效率,可维护性都可以有显著提高。
>
> > 其实还是"抽象"这个万能武器的作用,只要有牛人把容易出问题的东西隐藏起来,封装起来,给一个好用的抽象,对大部分程序员来说就能美好许多。
>
> > 例如Memory Consistency,让JVM或CLR那样在各CPU架构中统一起来,即便是没有并行库的支持,写并行程序已经可以轻松很多了。
>

> > 至于教育上......我觉得其实这个问题倒不是并行特有的,也不是并行上面表现的更彻底,而是(国内)本来就没多少人被教育好。


>
> > 例如计算机体系结构,操作系统等等。这虽然和并行有关,但也不是并行特有的东西。
>
> > Jeffrey Zhao
> > Blog:http://www.cnblogs.com/JeffreyZhao/
> > Twitter:https://twitter.com/jeffz_cn
>

> > *From:* Guancheng Chen <chenguanch...@gmail.com>
> > *Sent:* Monday, March 22, 2010 7:37 AM
> > *To:* TopLanguage <pon...@googlegroups.com>
> > *Subject:* [TL] {技术}{多线程}实施并行编程的五大障碍


>
> > 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> > 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> > (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> > Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> > 的看法。
>
> > ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看
>

> >http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...


> > )
>
> > 1. 遗留代码
> > 众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
> > 一大堆诸如data race, dependency, non-deterministic, memory consistency,
> > dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
> > 效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
> > 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
> > 能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
> > 没有dependence,并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化,从商业的角度上来讲,如果能
> > 有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码获得10%~30%的性能提升,那么它就已经能为公司节省大量成本了。
>
> > 2. 教育
> > 第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史了,不过在多核CPU出现之前那些并行编程都是"专家"们的玩
> > 具。那时候的并行编程大都是跑在集群、大型机或者服务器上,通过MPI(message passing model)或者SMP(对称多处理器,即一
> > 个主板上有多个单核CPU,属于shared memory model)来完成并行计算。Pthread标准是1995年建立的,之后出来了
> > Windows版的Win32 thread,后来又出来了"编译指导"、面向data parallel模型的OpenMP(OpenMP 3.0加
> > 入了task parallel支持),task parallel的鼻祖Click,Intel的Intel Thread Building
> > Block(task parallel),Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model),近几年随着
> > GPU的发展,Nvidia又开始搞CUDA(data-parallel),Apple一看不对,并行编程以后是主流啊,我得插一手,于是自己撑旗弄
> > 了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也
> > 要加入多线程支持,甚至连老古董Erlang也因为天生支持并行被重新热炒,总之随着摩尔定律在串行世界的失效,整个业界都开始被迫往并行编程方向发
> > 展。
>
> > 可是对程序员来说呢是什么情况呢?我们现在所接受的教育大都还是串行世界的那些算法和数据结构,高德纳在一篇访谈里说"在我看来,这种现象或多或少是由
> > 于硬件设计者已经无计可施了导致的,他们将Moore定律失效的责任推脱给软件开发者,而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线

> > 程的想法被证明是失败的,我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣?我几乎没有听说过,除了他们的诉苦。

Jeffrey Zhao

unread,
Mar 21, 2010, 9:42:22 PM3/21/10
to pon...@googlegroups.com
哈哈,广告好,扩展视野,那我继续做广告了……
 
微软其实很早就在搞Microsoft Accelerator项目,旨在利用DirectX进行计算,.NET项目。 http://research.microsoft.com/en-us/projects/Accelerator/
 
然后F#这边由于语言的支持良好,可以设计出丰富的表达式、DSL等Modeling Language,再由框架进行自动并行,解决问题可以很容易(已经2.0了)。
 
 
 
F# Optimization Modeling Language Utilizing Microsoft Solver Foundation http://code.msdn.microsoft.com/solverfoundationfs1
 
现在就等OpenCL如果有标准出来,肯定立马可以跟上个类库,哦耶。

Tinyfool

unread,
Mar 21, 2010, 9:46:51 PM3/21/10
to pon...@googlegroups.com
OpenCL早就出来标准了,而且在做各个平台的实现…

视野啊…

2010/3/22 Jeffrey Zhao <je...@live.com>

woo

unread,
Mar 21, 2010, 9:47:56 PM3/21/10
to pon...@googlegroups.com
C的pthread太重量级了,我觉得golang的go要好很多,虽然只是试验阶段

陨落雕

unread,
Mar 21, 2010, 9:49:58 PM3/21/10
to TopLanguage
言多必失啊,coalescing是写显存时候的问题,单词也拼错了......

> ...
>
> read more >>

Jeffrey Zhao

unread,
Mar 21, 2010, 9:51:27 PM3/21/10
to pon...@googlegroups.com
是嘛,我记得是提交了标准还在审核。
 
好吧,我去查了一下果然在08年12月1.0 Stable release了。

Changsheng Jiang

unread,
Mar 21, 2010, 10:19:14 PM3/21/10
to pon...@googlegroups.com
个人觉得最大障碍在工具上.

并行学术上研究得不少, 主要在算法和模型上. 工程上的工具, 多是自串行程序来设计的, 弄得复杂不堪. 并行需要语言和库两级支持, Pthreads 和 MPI 仅从库上入手, 让程序员处理各种重复且复杂的分发, 并发锁等. OpenMP好一些, 可惜目前只支持线程并行.

用 ErLang 等将并行设计在语言里的来做并行会容易得多, 得易于面向消息传递的隔离模型, 程序稳定易写. 模型和语言的性能是一个问题, 主要的问题还在用的人和实际并行项目不多.

调试工具就更少了. 有少数商业化的工具.

当然, 我是将可维护性归结为语言工具太差.

                                                     Changsheng Jiang


2010/3/22 Guancheng Chen <chengu...@gmail.com>

Milo Yip

unread,
Mar 21, 2010, 10:20:24 PM3/21/10
to pon...@googlegroups.com
我在等NVidia的Fermi和Nexus,想試做全域照明。
但怕買了Fermi後,機器也只是用來做做翻譯……

--
Milo Yip

Twitter @miloyip
http://www.cnblogs.com/miloyip/
http://miloyip.seezone.net/

Milo Yip

unread,
Mar 21, 2010, 10:21:10 PM3/21/10
to pon...@googlegroups.com
應該是「全局照明」

archer

unread,
Mar 22, 2010, 12:36:11 AM3/22/10
to pon...@googlegroups.com
工具的确是个问题,没有好的工具,很难快速推广。


2010/3/22 Changsheng Jiang <jiang...@gmail.com>

陨落雕

unread,
Mar 22, 2010, 1:10:25 AM3/22/10
to TopLanguage
我也想用Fermi来解一个和ray tracer类似的问题,话说NV招了好多搞ray tracer和hpc的大牛。

On Mar 21, 10:20 pm, Milo Yip <milo...@gmail.com> wrote:
> 我在等NVidia的Fermi和Nexus,想試做全域照明。
> 但怕買了Fermi後,機器也只是用來做做翻譯......


>
> 在 2010年3月22日上午9:51,Jeffrey Zhao <je...@live.com> 寫道:
>
> > 是嘛,我记得是提交了标准还在审核。
>
> > 好吧,我去查了一下果然在08年12月1.0 Stable release了。
>
> > Jeffrey Zhao
> > Blog:http://www.cnblogs.com/JeffreyZhao/
> > Twitter:https://twitter.com/jeffz_cn
> > From: Tinyfool
> > Sent: Monday, March 22, 2010 9:46 AM
> > To: pon...@googlegroups.com
> > Subject: Re: [TL] {技术}{多线程}实施并行编程的五大障碍

> > OpenCL早就出来标准了,而且在做各个平台的实现...
> > 视野啊...
>
> > 2010/3/22 Jeffrey Zhao <je...@live.com>
>
> >> 哈哈,广告好,扩展视野,那我继续做广告了......


>
> >> 微软其实很早就在搞Microsoft Accelerator项目,旨在利用DirectX进行计算,.NET项目。
> >>http://research.microsoft.com/en-us/projects/Accelerator/
>
> >> 然后F#这边由于语言的支持良好,可以设计出丰富的表达式、DSL等Modeling
> >> Language,再由框架进行自动并行,解决问题可以很容易(已经2.0了)。
>
> >> 这篇文章是个简单介绍:http://strangelights.com/blog/archive/2008/09/21/1628.aspx
>
> >> Microsoft Solver Foundation
> >>http://code.msdn.microsoft.com/solverfoundation
>
> >> F# Optimization Modeling Language Utilizing Microsoft Solver Foundation
> >>http://code.msdn.microsoft.com/solverfoundationfs1
>
> >> 现在就等OpenCL如果有标准出来,肯定立马可以跟上个类库,哦耶。
>
> >> Jeffrey Zhao
> >> Blog:http://www.cnblogs.com/JeffreyZhao/
> >> Twitter:https://twitter.com/jeffz_cn
> >> From: Tinyfool
> >> Sent: Monday, March 22, 2010 9:20 AM
> >> To: pon...@googlegroups.com
> >> Subject: Re: [TL] {技术}{多线程}实施并行编程的五大障碍
> >> 唉,本来不想广告的,既然赵姐夫都冒出来了,我也来广告一下
> >> Mac OS X最新的并行机制叫做GCD,靠,听名字就知道无比强大了吧?
> >> 还有支持显卡计算的OpenCL也是无比强大啊。
>
> >> 2010/3/22 Jeffrey Zhao <je...@live.com>
>
> >>> 我来做广告:有了并行库、或是F#这种语言的支持,并行编程已经容易很多了。开发效率,执行效率,可维护性都可以有显著提高。
>
> >>> 其实还是"抽象"这个万能武器的作用,只要有牛人把容易出问题的东西隐藏起来,封装起来,给一个好用的抽象,对大部分程序员来说就能美好许多。
>
> >>> 例如Memory Consistency,让JVM或CLR那样在各CPU架构中统一起来,即便是没有并行库的支持,写并行程序已经可以轻松很多了。
>

> >>> 至于教育上......我觉得其实这个问题倒不是并行特有的,也不是并行上面表现的更彻底,而是(国内)本来就没多少人被教育好。


>
> >>> 例如计算机体系结构,操作系统等等。这虽然和并行有关,但也不是并行特有的东西。
>
> >>> Jeffrey Zhao
> >>> Blog:http://www.cnblogs.com/JeffreyZhao/
> >>> Twitter:https://twitter.com/jeffz_cn
> >>> From: Guancheng Chen
> >>> Sent: Monday, March 22, 2010 7:37 AM
> >>> To: TopLanguage
> >>> Subject: [TL] {技术}{多线程}实施并行编程的五大障碍
> >>> 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> >>> 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> >>> (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> >>> Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> >>> 的看法。
>
> >>> ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看
>

> >>>http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...


> >>> )
>
> >>> 1. 遗留代码
> >>> 众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
> >>> 一大堆诸如data race, dependency, non-deterministic, memory consistency,
> >>> dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
> >>> 效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
> >>> 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
> >>> 能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
> >>> 没有dependence,并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化,从商业的角度上来讲,如果能
> >>> 有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码获得10%~30%的性能提升,那么它就已经能为公司节省大量成本了。
>
> >>> 2. 教育
> >>> 第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史了,不过在多核CPU出现之前那些并行编程都是"专家"们的玩
> >>> 具。那时候的并行编程大都是跑在集群、大型机或者服务器上,通过MPI(message passing model)或者SMP(对称多处理器,即一
> >>> 个主板上有多个单核CPU,属于shared memory model)来完成并行计算。Pthread标准是1995年建立的,之后出来了
> >>> Windows版的Win32 thread,后来又出来了"编译指导"、面向data parallel模型的OpenMP(OpenMP 3.0加
> >>> 入了task parallel支持),task parallel的鼻祖Click,Intel的Intel Thread Building
> >>> Block(task parallel),Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model),近几年随着
> >>> GPU的发展,Nvidia又开始搞CUDA(data-parallel),Apple一看不对,并行编程以后是主流啊,我得插一手,于是自己撑旗弄
> >>> 了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也
> >>> 要加入多线程支持,甚至连老古董Erlang也因为天生支持并行被重新热炒,总之随着摩尔定律在串行世界的失效,整个业界都开始被迫往并行编程方向发
> >>> 展。
>
> >>> 可是对程序员来说呢是什么情况呢?我们现在所接受的教育大都还是串行世界的那些算法和数据结构,高德纳在一篇访谈里说"在我看来,这种现象或多或少是由
> >>> 于硬件设计者已经无计可施了导致的,他们将Moore定律失效的责任推脱给软件开发者,而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线

> >>> 程的想法被证明是失败的,我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣?我几乎没有听说过,除了他们的诉苦。


> >>> 尽管我们学院那些搞硬件的家伙一直想让我相信我是错的",可见硬件发展被迫向多核转移直接导致程序员们免费的午餐已经结束了。那么程序员现在受到良好的
> >>> 并行编程教育了吗?很显然,现在随便问一个普通的程序员:"你觉得并行编程容易么?",十有八九会说"我觉得很难"。前一阵有人讨论服务器编程用多线程
> >>> 好还是多进程好?其实根本原因就在于哪怕多线程有性能优势,可是isolation的多进程模式能在programming productivity
> >>> 和performance之间找到比较好的折衷,所以国内很有服务器开发者都选择了多进程(例如云风)。从大趋势上来讲,不管是研究体系机构的,还是写
> >>> OS/Compiler的,还是定义编程语言的,现在都在积极努力的为广大的程序员提供一个更容易使用的并行编程模型,Intel这几年不也在搞多核培
> >>> 训么,这都是好现象,但是,离真正的全民并行编程时代还有相当长的路要走。近几年的IT技术热门书单里面很少有并行编程的书籍就是个很好的写照。
>
> >>> 3. 工具
> >>> 工欲善其事,必先利其器。那么现阶段我们能用的,并且好用的并行编程工具有多少呢(欢迎大家补充)?
>
> >>> (1) IDE: Intel Parallel Studio,微软马上出来的VS2010算一个,Sun的Sun Studio(不知道它的未来如
> >>> 何,但是它本来就很小众),Nvidia的CUDA平台什么的就先不算了
> >>> (2) Compiler: Intel的ICC(能自动并行化一些代码),Nema Labs的FASThread(针对遗留代码的解决方案,能快速
> >>> 可靠的指导程序员实施并行化)
> >>> (3) Performance Tuning: Intel Vtune Analyzer(综合性能分析),Thread profiler,
> >>> Acumem的Thread Spotter(针对多核Cache的性能分析和优化)
> >>> (4) Debugging: Petra的Jinx
>
> >>> 总体上我个人觉得它们对程序员来说确实有用,但是前提条件是你要会用。这其实又跟第二点"教育"有很大关系了。
>
> >>> 4. 对众核的恐惧
> >>> 现在我们看到4核已经非常普遍了,等过几年那可就是8核,16核,32核了。怎样确保你的代码在核数倍增的趋势下仍能有很好的性能,很好的可伸缩性?这
>

> ...
>
> read more >>

Guancheng Chen

unread,
Mar 22, 2010, 1:48:14 AM3/22/10
to TopLanguage
微软好像已经推出了跟OpenCL类似的Direct Compute,也能搞GPU CPU混合计算

On 3月22日, 上午2时42分, "Jeffrey Zhao" <je...@live.com> wrote:
> 哈哈,广告好,扩展视野,那我继续做广告了......


>
> 微软其实很早就在搞Microsoft Accelerator项目,旨在利用DirectX进行计算,.NET项目。http://research.microsoft.com/en-us/projects/Accelerator/
>
> 然后F#这边由于语言的支持良好,可以设计出丰富的表达式、DSL等Modeling Language,再由框架进行自动并行,解决问题可以很容易(已经2.0了)。
>
> 这篇文章是个简单介绍:http://strangelights.com/blog/archive/2008/09/21/1628.aspx
>

> Microsoft Solver Foundationhttp://code.msdn.microsoft.com/solverfoundation
>
> F# Optimization Modeling Language Utilizing Microsoft Solver Foundationhttp://code.msdn.microsoft.com/solverfoundationfs1


>
> 现在就等OpenCL如果有标准出来,肯定立马可以跟上个类库,哦耶。
>
> Jeffrey Zhao
> Blog:http://www.cnblogs.com/JeffreyZhao/
> Twitter:https://twitter.com/jeffz_cn
>
> From: Tinyfool
> Sent: Monday, March 22, 2010 9:20 AM
> To: pon...@googlegroups.com
> Subject: Re: [TL] {技术}{多线程}实施并行编程的五大障碍
>
> 唉,本来不想广告的,既然赵姐夫都冒出来了,我也来广告一下
>
> Mac OS X最新的并行机制叫做GCD,靠,听名字就知道无比强大了吧?
>
> 还有支持显卡计算的OpenCL也是无比强大啊。
>
> 2010/3/22 Jeffrey Zhao <je...@live.com>
>
> 我来做广告:有了并行库、或是F#这种语言的支持,并行编程已经容易很多了。开发效率,执行效率,可维护性都可以有显著提高。
>
> 其实还是"抽象"这个万能武器的作用,只要有牛人把容易出问题的东西隐藏起来,封装起来,给一个好用的抽象,对大部分程序员来说就能美好许多。
>
> 例如Memory Consistency,让JVM或CLR那样在各CPU架构中统一起来,即便是没有并行库的支持,写并行程序已经可以轻松很多了。
>

> 至于教育上......我觉得其实这个问题倒不是并行特有的,也不是并行上面表现的更彻底,而是(国内)本来就没多少人被教育好。


>
> 例如计算机体系结构,操作系统等等。这虽然和并行有关,但也不是并行特有的东西。
>
> Jeffrey Zhao
> Blog:http://www.cnblogs.com/JeffreyZhao/
> Twitter:https://twitter.com/jeffz_cn
>
> From: Guancheng Chen
> Sent: Monday, March 22, 2010 7:37 AM
> To: TopLanguage
> Subject: [TL] {技术}{多线程}实施并行编程的五大障碍
>
> 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> 的看法。
>
> ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看

> http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...


> )
>
> 1. 遗留代码
> 众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
> 一大堆诸如data race, dependency, non-deterministic, memory consistency,
> dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
> 效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
> 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
> 能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
> 没有dependence,并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化,从商业的角度上来讲,如果能
> 有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码获得10%~30%的性能提升,那么它就已经能为公司节省大量成本了。
>
> 2. 教育
> 第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史了,不过在多核CPU出现之前那些并行编程都是"专家"们的玩
> 具。那时候的并行编程大都是跑在集群、大型机或者服务器上,通过MPI(message passing model)或者SMP(对称多处理器,即一
> 个主板上有多个单核CPU,属于shared memory model)来完成并行计算。Pthread标准是1995年建立的,之后出来了
> Windows版的Win32 thread,后来又出来了"编译指导"、面向data parallel模型的OpenMP(OpenMP 3.0加
> 入了task parallel支持),task parallel的鼻祖Click,Intel的Intel Thread Building
> Block(task parallel),Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model),近几年随着
> GPU的发展,Nvidia又开始搞CUDA(data-parallel),Apple一看不对,并行编程以后是主流啊,我得插一手,于是自己撑旗弄
> 了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也
> 要加入多线程支持,甚至连老古董Erlang也因为天生支持并行被重新热炒,总之随着摩尔定律在串行世界的失效,整个业界都开始被迫往并行编程方向发
> 展。
>
> 可是对程序员来说呢是什么情况呢?我们现在所接受的教育大都还是串行世界的那些算法和数据结构,高德纳在一篇访谈里说"在我看来,这种现象或多或少是由
> 于硬件设计者已经无计可施了导致的,他们将Moore定律失效的责任推脱给软件开发者,而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线

> 程的想法被证明是失败的,我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣?我几乎没有听说过,除了他们的诉苦。


> 尽管我们学院那些搞硬件的家伙一直想让我相信我是错的",可见硬件发展被迫向多核转移直接导致程序员们免费的午餐已经结束了。那么程序员现在受到良好的
> 并行编程教育了吗?很显然,现在随便问一个普通的程序员:"你觉得并行编程容易么?",十有八九会说"我觉得很难"。前一阵有人讨论服务器编程用多线程
> 好还是多进程好?其实根本原因就在于哪怕多线程有性能优势,可是isolation的多进程模式能在programming productivity
> 和performance之间找到比较好的折衷,所以国内很有服务器开发者都选择了多进程(例如云风)。从大趋势上来讲,不管是研究体系机构的,还是写
> OS/Compiler的,还是定义编程语言的,现在都在积极努力的为广大的程序员提供一个更容易使用的并行编程模型,Intel这几年不也在搞多核培
> 训么,这都是好现象,但是,离真正的全民并行编程时代还有相当长的路要走。近几年的IT技术热门书单里面很少有并行编程的书籍就是个很好的写照。
>
> 3. 工具
> 工欲善其事,必先利其器。那么现阶段我们能用的,并且好用的并行编程工具有多少呢(欢迎大家补充)?
>
> (1) IDE: Intel Parallel Studio,微软马上出来的VS2010算一个,Sun的Sun Studio(不知道它的未来如
> 何,但是它本来就很小众),Nvidia的CUDA平台什么的就先不算了
> (2) Compiler: Intel的ICC(能自动并行化一些代码),Nema Labs的FASThread(针对遗留代码的解决方案,能快速
> 可靠的指导程序员实施并行化)
> (3) Performance Tuning: Intel Vtune Analyzer(综合性能分析),Thread profiler,
> Acumem的Thread Spotter(针对多核Cache的性能分析和优化)
> (4) Debugging: Petra的Jinx
>
> 总体上我个人觉得它们对程序员来说确实有用,但是前提条件是你要会用。这其实又跟第二点"教育"有很大关系了。
>
> 4. 对众核的恐惧
> 现在我们看到4核已经非常普遍了,等过几年那可就是8核,16核,32核了。怎样确保你的代码在核数倍增的趋势下仍能有很好的性能,很好的可伸缩性?这
> 真的是个问题。我现在所做的研究就是多线程程序中锁竞争的性能分析,目的就是为了帮助程序员更好的解决由锁竞争造成的性能瓶颈。实际上,为了得到很好的
> 可伸缩性,程序员需要往往需要使用并行友好的数据结构(例如concurrent hash map),使用细粒度的锁甚至无锁编程,设计data
> parallel的算法,性能调优(例如典型的false sharing问题)等等等等,这其中每一项都是不小的挑战。我曾经翻译过的一篇文章对设计
> 多线程程序提供了一些有用的建议。
>
> 5. 可维护性
> 毫无疑问,我们希望并行代码能够与现存的runtime系统、build系统以及其他现有代码一起正确的工作,我们更希望这些并行代码易于理解、便于维

> 护并且有较长的生命周期。可是现阶段真正掌握并行编程的程序员少之又少,而且并行编程又是这么困难,哪怕你对这些并行代码只是做一些小小的改动都很有可...
>
> 阅读更多 >>

Kula

unread,
Mar 22, 2010, 1:48:57 AM3/22/10
to pon...@googlegroups.com
我觉得 想要并行开发 必须绕开c/c++

2010/3/22 Guancheng Chen <chengu...@gmail.com>

Guancheng Chen

unread,
Mar 22, 2010, 1:52:54 AM3/22/10
to TopLanguage
很有意思的事情是我上次问过一个负责定制OpenCL的哥们,"从商业角度上讲,苹果为什么要自己搞一个新标准?" 他就说那个时候苹果意识到未来这种
通用并行计算平台的重要性,而为了保证最大的商业利益就选择自己重新搞一个新标准而不是跟当时已有CUDA的Nvidia合作,结果现在NV也开始支持
OpenCL,但是他们最新的一本教材里说到"根据我们的经验,学习OpenCL最好的办法是先学CUDA"

> > >>> 4. 对众核的恐惧...
>
> 阅读更多 >>

Guancheng Chen

unread,
Mar 22, 2010, 2:00:20 AM3/22/10
to TopLanguage
不知道您觉得现有的工具哪些个最趁手呢?

On 3月22日, 上午3时19分, Changsheng Jiang <jiangzuo...@gmail.com> wrote:
> 个人觉得最大障碍在工具上.
>
> 并行学术上研究得不少, 主要在算法和模型上. 工程上的工具, 多是自串行程序来设计的, 弄得复杂不堪. 并行需要语言和库两级支持, Pthreads 和
> MPI 仅从库上入手, 让程序员处理各种重复且复杂的分发, 并发锁等. OpenMP好一些, 可惜目前只支持线程并行.
>
> 用 ErLang 等将并行设计在语言里的来做并行会容易得多, 得易于面向消息传递的隔离模型, 程序稳定易写. 模型和语言的性能是一个问题,
> 主要的问题还在用的人和实际并行项目不多.
>
> 调试工具就更少了. 有少数商业化的工具.
>
> 当然, 我是将可维护性归结为语言工具太差.
>
> Changsheng Jiang
>

> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>


>
>
>
> > 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> > 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> > (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> > Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> > 的看法。
>
> > ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看
>

> >http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...


> > )
>
> > 1. 遗留代码
> > 众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
> > 一大堆诸如data race, dependency, non-deterministic, memory consistency,
> > dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
> > 效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
> > 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
> > 能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
> > 没有dependence,并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化,从商业的角度上来讲,如果能
> > 有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码获得10%~30%的性能提升,那么它就已经能为公司节省大量成本了。
>
> > 2. 教育
> > 第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史了,不过在多核CPU出现之前那些并行编程都是"专家"们的玩
> > 具。那时候的并行编程大都是跑在集群、大型机或者服务器上,通过MPI(message passing model)或者SMP(对称多处理器,即一
> > 个主板上有多个单核CPU,属于shared memory model)来完成并行计算。Pthread标准是1995年建立的,之后出来了
> > Windows版的Win32 thread,后来又出来了"编译指导"、面向data parallel模型的OpenMP(OpenMP 3.0加
> > 入了task parallel支持),task parallel的鼻祖Click,Intel的Intel Thread Building
> > Block(task parallel),Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model),近几年随着
> > GPU的发展,Nvidia又开始搞CUDA(data-parallel),Apple一看不对,并行编程以后是主流啊,我得插一手,于是自己撑旗弄
> > 了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也
> > 要加入多线程支持,甚至连老古董Erlang也因为天生支持并行被重新热炒,总之随着摩尔定律在串行世界的失效,整个业界都开始被迫往并行编程方向发
> > 展。
>
> > 可是对程序员来说呢是什么情况呢?我们现在所接受的教育大都还是串行世界的那些算法和数据结构,高德纳在一篇访谈里说"在我看来,这种现象或多或少是由
> > 于硬件设计者已经无计可施了导致的,他们将Moore定律失效的责任推脱给软件开发者,而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线

> > 程的想法被证明是失败的,我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣?我几乎没有听说过,除了他们的诉苦。

Guancheng Chen

unread,
Mar 22, 2010, 2:03:18 AM3/22/10
to TopLanguage
哈哈 是想绕开C++那些本来就复杂的要死的feature么?是不是如果有一门新的易用的编程语言会比诸如给C++添加thread特性的方法要
好?

On 3月22日, 上午6时48分, Kula <kulas...@gmail.com> wrote:
> 我觉得 想要并行开发 必须绕开c/c++
>

> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>

> > > parallel的算法,性能调优(例如典型的false...
>
> 阅读更多 >>

Guancheng Chen

unread,
Mar 22, 2010, 2:06:33 AM3/22/10
to TopLanguage
我还以为GCD是指最大公约数,搜了一下原来也是类似task parallelism的库 受您蛊惑 下一次我要买Macbook Pro了。。。

On 3月22日, 上午2时20分, Tinyfool <tinyf...@gmail.com> wrote:
> 唉,本来不想广告的,既然赵姐夫都冒出来了,我也来广告一下
>
> Mac OS X最新的并行机制叫做GCD,靠,听名字就知道无比强大了吧?
>
> 还有支持显卡计算的OpenCL也是无比强大啊。
>
> 2010/3/22 Jeffrey Zhao <je...@live.com>
>
>
>
>
>
> > 我来做广告:有了并行库、或是F#这种语言的支持,并行编程已经容易很多了。开发效率,执行效率,可维护性都可以有显著提高。
>
> > 其实还是"抽象"这个万能武器的作用,只要有牛人把容易出问题的东西隐藏起来,封装起来,给一个好用的抽象,对大部分程序员来说就能美好许多。
>
> > 例如Memory Consistency,让JVM或CLR那样在各CPU架构中统一起来,即便是没有并行库的支持,写并行程序已经可以轻松很多了。
>

> > 至于教育上......我觉得其实这个问题倒不是并行特有的,也不是并行上面表现的更彻底,而是(国内)本来就没多少人被教育好。


>
> > 例如计算机体系结构,操作系统等等。这虽然和并行有关,但也不是并行特有的东西。
>
> > Jeffrey Zhao
> > Blog:http://www.cnblogs.com/JeffreyZhao/
> > Twitter:https://twitter.com/jeffz_cn
>

> > *From:* Guancheng Chen <chenguanch...@gmail.com>
> > *Sent:* Monday, March 22, 2010 7:37 AM
> > *To:* TopLanguage <pon...@googlegroups.com>

> > *Subject:* [TL] {技术}{多线程}实施并行编程的五大障碍


>
> > 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> > 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> > (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> > Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> > 的看法。
>
> > ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看
>

> >http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...


> > )
>
> > 1. 遗留代码
> > 众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
> > 一大堆诸如data race, dependency, non-deterministic, memory consistency,
> > dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
> > 效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
> > 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
> > 能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
> > 没有dependence,并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化,从商业的角度上来讲,如果能
> > 有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码获得10%~30%的性能提升,那么它就已经能为公司节省大量成本了。
>
> > 2. 教育
> > 第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史了,不过在多核CPU出现之前那些并行编程都是"专家"们的玩
> > 具。那时候的并行编程大都是跑在集群、大型机或者服务器上,通过MPI(message passing model)或者SMP(对称多处理器,即一
> > 个主板上有多个单核CPU,属于shared memory model)来完成并行计算。Pthread标准是1995年建立的,之后出来了
> > Windows版的Win32 thread,后来又出来了"编译指导"、面向data parallel模型的OpenMP(OpenMP 3.0加
> > 入了task parallel支持),task parallel的鼻祖Click,Intel的Intel Thread Building
> > Block(task parallel),Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model),近几年随着
> > GPU的发展,Nvidia又开始搞CUDA(data-parallel),Apple一看不对,并行编程以后是主流啊,我得插一手,于是自己撑旗弄
> > 了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也
> > 要加入多线程支持,甚至连老古董Erlang也因为天生支持并行被重新热炒,总之随着摩尔定律在串行世界的失效,整个业界都开始被迫往并行编程方向发
> > 展。
>
> > 可是对程序员来说呢是什么情况呢?我们现在所接受的教育大都还是串行世界的那些算法和数据结构,高德纳在一篇访谈里说"在我看来,这种现象或多或少是由
> > 于硬件设计者已经无计可施了导致的,他们将Moore定律失效的责任推脱给软件开发者,而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线

> > 程的想法被证明是失败的,我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣?我几乎没有听说过,除了他们的诉苦。

Changsheng Jiang

unread,
Mar 22, 2010, 2:09:17 AM3/22/10
to pon...@googlegroups.com
说来惭愧, 接触并行时间不长, 没什么实际经验, 只写过几个并行程序.

感觉 MPI + OpenMP 倒算好用. 简单的单机程序, 用OpenMP并行, 添加几个编译指令就可以. 复杂点的, 用MPI, 也能忍, 只是需要重新设计一下程序和算法.

除了简单的打印, 跟踪一个进程, 不知道怎么调试并行程序. 没有专用平台如NUMA等的编程经验.

                                                     Changsheng Jiang


2010/3/22 Guancheng Chen <chengu...@gmail.com>
To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Doyle

unread,
Mar 22, 2010, 2:13:06 AM3/22/10
to pon...@googlegroups.com
2010/3/22 Guancheng Chen <chengu...@gmail.com>

我还以为GCD是指最大公约数,搜了一下原来也是类似task parallelism的库 受您蛊惑 下一次我要买Macbook Pro了。。。


我也是被蛊惑了...所以向老婆提申请来着,结果被否掉了...
 
> myTwitter:http://twitter.com/tinyfool

To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Tinyfool

unread,
Mar 22, 2010, 2:17:23 AM3/22/10
to pon...@googlegroups.com
热烈支持,哈哈

2010/3/22 Guancheng Chen <chengu...@gmail.com>

Guancheng Chen

unread,
Mar 22, 2010, 2:35:27 AM3/22/10
to TopLanguage
我个人也觉得OpenMP是目前比较好用的并行方式。像您这样设计算法的程序员,是不是基本上也是只对串行算法做优化改进,然后性能瓶颈比较大的部分才
考虑实施并行化?

On 3月22日, 上午7时09分, Changsheng Jiang <jiangzuo...@gmail.com> wrote:
> 说来惭愧, 接触并行时间不长, 没什么实际经验, 只写过几个并行程序.
>
> 感觉 MPI + OpenMP 倒算好用. 简单的单机程序, 用OpenMP并行, 添加几个编译指令就可以. 复杂点的, 用MPI, 也能忍,
> 只是需要重新设计一下程序和算法.
>
> 除了简单的打印, 跟踪一个进程, 不知道怎么调试并行程序. 没有专用平台如NUMA等的编程经验.
>
> Changsheng Jiang
>

> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>

Changsheng Jiang

unread,
Mar 22, 2010, 2:40:35 AM3/22/10
to pon...@googlegroups.com
说设计算法, 其实, 是实现算法, 找到合适的算法实现了.

五个障碍中的第一条在, 人力有限, 只能并行不并行不行的部分.

                                                     Changsheng Jiang


2010/3/22 Guancheng Chen <chengu...@gmail.com>
To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Alleluia

unread,
Mar 22, 2010, 3:06:12 AM3/22/10
to TopLanguage
Parallelism 说到底是算法问题.Parallelism与Concurrency不同,Concurrency所面对的问题相对的单一可以
让一群有经验的专家来实现一套通用库或者语言来提供一个基本的编程框架.而在Parallelism上,具体的不同问题,其所需要并行的算法是根本不同
的.原因在于不同的问题,其内部的DataDependency的结构完全不同,不同的Data Dependency的结构,需要构造不同的算法.即
便是相同的Data Dependency,在不同的颗粒度下,在不同的硬件条件下所采用的算法也是完全不同的.因为一旦出现Data
Dependency也就意味着并行计算模块之间需要进行通信.从以计算节点为单位的分布式并行,到多核CPU上的Numa结构,到SIMD上的向量处
理器,其计算单元之间的通信手段,通信效率简直天差地别.比如说,在SMP上最常见的并行算法,work stealing也就是Intel的TBB,
是建立在两个条件下第一个是CPU的Cache机制上,这使得通常在内存的之间的数据搬运消耗非常小,第二个是SMP上计算单元相对的少,因此每个计算
单元被分配到的任务就相对的重。其开销远远大于通信的开销,因此这种机制在SMP上相对的划算.但是如果你要在GPU上做Work Stealing就
完全不可行,因为GPU的运算单元数量极多,被分配到的任务就相对来说的非常轻量,CUDA上的一个thread很多时候运算一次的时间不会超过
10us,而一次跨Block的线程之间的通信开销就往往要达到100us左右,再加上目前GPU上的Cache机制非常落后导致了需要频繁的通信开销
的Work Stealing在GPU上是非常不划算得.
所以我个人认为在硬件架构没有更多的突破之前,OpenCL这种东西是没有任何生命力的.不要说CPU的并行与GPU之间差异巨大,就是不同的GPU之
间AMD与Nvidia两个也是各自为政,一个平台上跑得非常快的东西,在另外一个平台极大的可能是龟速.其最终的结果估计就是跟Java的
write once run everywhere一样是个大笑话.

Alleluia

unread,
Mar 22, 2010, 3:18:37 AM3/22/10
to TopLanguage
其实并行计算这个东西,对现有的基于文本内容的程序意义不是很大.因为文本内容的数据量增加是线性的.而相对来说,视频音频的数据就完全不同是按平方甚
至是指数增加的.一个文本长度增加一倍,数据量也就增加一倍.而一张图片,长宽增加一倍,数据量要增加四倍.一个既有的算法在没有大的理论突破的前提
下,在特定的硬件平台上能够优化加速5-6倍已经是了不得了.但是对于多媒体数据来说,这个加速真的不算什么.一个算法在720p上快3,4倍,换到
1080p的也就是达到了720p上不加速的效果而已.

Guancheng Chen

unread,
Mar 22, 2010, 3:21:04 AM3/22/10
to TopLanguage
绝大部分的观点Can't agree more.其实这也是为什么我引用了高老爷子那段话的原因,因为程序的本质就是数据结构和算法,你要没有非常适
合并行的算法那简直就是巧妇难为无米之炊。但是有疑问的一点是关于Parallelism和Concurrency这两个单词的区别,实际上这也是非常
有意思的一件事情,Sun的多线程指南上写的是: Parallelism is a condition that arises when at
least two threads are executing simultaneously, while concurrency is a
condition that exists when at least two threads are making progress.
Therefore concurrency is a more generalized form of parallelism that
can include time-slicing as a form of virtual parallelism.不知道您怎么看?

> > > > (3) Performance Tuning: Intel Vtune Analyzer(综合性能分析),Thread profiler,...
>
> 阅读更多 >>

Alleluia

unread,
Mar 22, 2010, 5:19:27 AM3/22/10
to TopLanguage
Concurrency 说到底纯粹就是一个IO问题.而IO问题本质上是和计算完全无关的事情,不存在能不能行可不可计算的问题.因此它相对来说非常
单纯。他更多的是一种类似时钟同步的问题,如果你把IO事件想像成一种时钟信号.其实时钟本来也就是一堆信号而已.如果你做过Circuit 的东西就
会明白,IO只是在不同的时序下进行数据采样.比如最简单的同步时钟,所有的时序电路公用一个时钟,把不同的电路安排在不同的时序边沿上触发.当然更复
杂异步逻辑的道理也是一样的.放到宏观的Concurrency的问题的实质并没有多大改变,只不过CPU依靠PC指针的移动把这种电路上的时序处理软
件化了.

而Parallelism更多的是需要考虑计算问题同时还要兼顾IO.Parallelism首先要回答的是一个东西是不是可并行的.回答完这个问题
后,如果可并行那么在什么样的硬件设备上并行是最合适的这样一个问题.在Parallelism中需要考虑的的IO也不仅仅是来自于网络更多是,缓存,
内存,磁盘,总线等等.其实我觉得,在Parallelism下你总是处于一个矛盾状态,颗粒度越小的并行获得的计算资源的利用率也就越大加速比就越
大,但是同时通信系统的工作也就越是繁忙整个运算过程浪费在通信消耗上的时间也就越多.
这个当中的tradeoff是非常困难的.很多时候速度不快,完全不是因为你的核心不够多,而是你的通信速度不够高.

> ...
>
> 阅读更多 >>

Alleluia

unread,
Mar 22, 2010, 5:34:40 AM3/22/10
to TopLanguage
Microsoft Accelerator稍稍看了一下这个东西,是05年的工作.这个东西其实已经不新鲜了.大概跟PyCUDA
array-processing operations such as those which frequently arise in
domains.
但是我要说的是,这个领域相对于真正需要的并行计算实在是太少太少.比如说他强调的 image processing and
scientific computing,当中很多非线性滤波的并行算法就不能用这个架构来做.

On 3月22日, 上午9时42分, "Jeffrey Zhao" <je...@live.com> wrote:
> 哈哈,广告好,扩展视野,那我继续做广告了......
>

> 微软其实很早就在搞Microsoft Accelerator项目,旨在利用DirectX进行计算,.NET项目。http://research.microsoft.com/en-us/projects/Accelerator/
>
> 然后F#这边由于语言的支持良好,可以设计出丰富的表达式、DSL等Modeling Language,再由框架进行自动并行,解决问题可以很容易(已经2.0了)。
>
> 这篇文章是个简单介绍:http://strangelights.com/blog/archive/2008/09/21/1628.aspx
>

> Microsoft Solver Foundationhttp://code.msdn.microsoft.com/solverfoundation
>
> F# Optimization Modeling Language Utilizing Microsoft Solver Foundationhttp://code.msdn.microsoft.com/solverfoundationfs1


>
> 现在就等OpenCL如果有标准出来,肯定立马可以跟上个类库,哦耶。
>
> Jeffrey Zhao
> Blog:http://www.cnblogs.com/JeffreyZhao/
> Twitter:https://twitter.com/jeffz_cn
>
> From: Tinyfool
> Sent: Monday, March 22, 2010 9:20 AM
> To: pon...@googlegroups.com
> Subject: Re: [TL] {技术}{多线程}实施并行编程的五大障碍
>
> 唉,本来不想广告的,既然赵姐夫都冒出来了,我也来广告一下
>
> Mac OS X最新的并行机制叫做GCD,靠,听名字就知道无比强大了吧?
>
> 还有支持显卡计算的OpenCL也是无比强大啊。
>
> 2010/3/22 Jeffrey Zhao <je...@live.com>
>
> 我来做广告:有了并行库、或是F#这种语言的支持,并行编程已经容易很多了。开发效率,执行效率,可维护性都可以有显著提高。
>
> 其实还是"抽象"这个万能武器的作用,只要有牛人把容易出问题的东西隐藏起来,封装起来,给一个好用的抽象,对大部分程序员来说就能美好许多。
>
> 例如Memory Consistency,让JVM或CLR那样在各CPU架构中统一起来,即便是没有并行库的支持,写并行程序已经可以轻松很多了。
>

> 至于教育上......我觉得其实这个问题倒不是并行特有的,也不是并行上面表现的更彻底,而是(国内)本来就没多少人被教育好。


>
> 例如计算机体系结构,操作系统等等。这虽然和并行有关,但也不是并行特有的东西。
>
> Jeffrey Zhao
> Blog:http://www.cnblogs.com/JeffreyZhao/
> Twitter:https://twitter.com/jeffz_cn
>
> From: Guancheng Chen
> Sent: Monday, March 22, 2010 7:37 AM
> To: TopLanguage
> Subject: [TL] {技术}{多线程}实施并行编程的五大障碍
>
> 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> 的看法。
>
> ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看

> http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...


> )
>
> 1. 遗留代码
> 众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
> 一大堆诸如data race, dependency, non-deterministic, memory consistency,
> dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
> 效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
> 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
> 能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
> 没有dependence,并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化,从商业的角度上来讲,如果能
> 有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码获得10%~30%的性能提升,那么它就已经能为公司节省大量成本了。
>
> 2. 教育
> 第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史了,不过在多核CPU出现之前那些并行编程都是"专家"们的玩
> 具。那时候的并行编程大都是跑在集群、大型机或者服务器上,通过MPI(message passing model)或者SMP(对称多处理器,即一
> 个主板上有多个单核CPU,属于shared memory model)来完成并行计算。Pthread标准是1995年建立的,之后出来了
> Windows版的Win32 thread,后来又出来了"编译指导"、面向data parallel模型的OpenMP(OpenMP 3.0加
> 入了task parallel支持),task parallel的鼻祖Click,Intel的Intel Thread Building
> Block(task parallel),Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model),近几年随着
> GPU的发展,Nvidia又开始搞CUDA(data-parallel),Apple一看不对,并行编程以后是主流啊,我得插一手,于是自己撑旗弄
> 了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也
> 要加入多线程支持,甚至连老古董Erlang也因为天生支持并行被重新热炒,总之随着摩尔定律在串行世界的失效,整个业界都开始被迫往并行编程方向发
> 展。
>
> 可是对程序员来说呢是什么情况呢?我们现在所接受的教育大都还是串行世界的那些算法和数据结构,高德纳在一篇访谈里说"在我看来,这种现象或多或少是由
> 于硬件设计者已经无计可施了导致的,他们将Moore定律失效的责任推脱给软件开发者,而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线

> 程的想法被证明是失败的,我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣?我几乎没有听说过,除了他们的诉苦。

> ...
>
> 阅读更多 >>

Guancheng Chen

unread,
Mar 22, 2010, 7:04:55 AM3/22/10
to TopLanguage
您的观点很有新意,我以前没有过用IO来区分Concurrency和Parallelism的想法,我猜测可能跟您的网络/通信背景有关。其实我觉得
从广义上来讲Parallelism和Concurrency是基本重合的两个概念,只不过可能Concurrency稍微偏工程一点,
Parallelism稍微偏研究一点。例如Herb Sutter要出的新书叫Effective Concurrency,而市面上其他讲并行计算
的书不少也使用Parallel相关的词汇。

另外您这句话我有些不赞同:"颗粒度越小的并行获得的计算资源的利用率也就越大加速比就越大",拿一个计算密集型的嵌套循环举例,对比并行外层循环和并
行内层循环,无疑你在并行化外层循环时的性能加速比更好,而这时候你的并行度是粗粒度的(内循环并行相对来说是细粒度的)。当然,粗/细粒度的选择确实
是个tradeoff,拿锁竞争来说,细粒度的锁意味着更好的Scalability,但是你加锁/解锁的次数相比组粒度所来说增加了,而这种加锁/解
锁的操作是有开销的,所以需要在锁操作本身的开销和程序的Scalability中做一个平衡。

多谢指教!

> > > > > > 了个针对CPU和GPU混合编程的OpenCL,微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库,马上C++0x也...
>
> 阅读更多 >>

Googol Lee

unread,
Mar 22, 2010, 8:30:34 AM3/22/10
to TopLanguage
彻底来晚了......我是来广告golang的!大并发IO还是csp模型的语言更靠谱!

不过golang在cpu密集的并发上不知道效果会怎么样,就现在的表现来看比erlang好,但还赶不上c/c++

Jeffrey Zhao

unread,
Mar 22, 2010, 9:11:43 AM3/22/10
to pon...@googlegroups.com
������F#���������һ�����ŵķ�ʽ��ʵ��CSP�ġ�

���������ڴ���Ժ�ڲ��������Ͻ���F#�ƹ㣬������

Twitter: @jeffz_cn

--------------------------------------------------
From: "Googol Lee" <goog...@gmail.com>
Sent: Monday, March 22, 2010 8:30 PM
To: "TopLanguage" <pon...@googlegroups.com>
Subject: [TL] Re: {����}{���߳�}ʵʩ���б�̵�����ϰ�

> ����������......���������golang�ģ��󲢷�IO����cspģ�͵����Ը��ף�
>
> ����golang��cpu�ܼ��IJ����ϲ�֪��Ч�����ô������ڵı���������erlang�ã������ϲ���c/c++


>
> On Mar 22, 9:20 am, Tinyfool <tinyf...@gmail.com> wrote:

>> ��������������ģ���Ȼ�Խ��ð�����ˣ���Ҳ�����һ��
>>
>> Mac OS X���µIJ��л��ƽ���GCD�����������־�֪���ޱ�ǿ���˰ɣ�
>>
>> ����֧���Կ������OpenCLҲ���ޱ�ǿ�󰡡�
>>
>> 2010/3/22 Jeffrey Zhao <je...@live.com>
>>
>>
>>
>> > ��������棺���˲��п⡢����F#�������Ե�֧�֣����б���Ѿ����׺ܶ��ˡ�����Ч�ʣ�ִ��Ч�ʣ���ά���Զ�������������ߡ�
>>
>> > ��ʵ����"����"����������������ã�ֻҪ��ţ�˰����׳�����Ķ���������������װ��������һ�����õij��󣬶Դ󲿷ֳ���Ա��˵����������ࡣ
>>
>> > ����Memory Consistency����JVM��CLR�����ڸ�CPU�ܹ���ͳһ������������û�в��п��֧�֣�д���г����Ѿ��������ɺܶ��ˡ�
>>
>> > ���ڽ�����......�Ҿ�����ʵ������⵹���Dz������еģ�Ҳ���Dz���������ֵĸ�ף����ǣ����ڣ�������û�����˱�����á�
>>
>> > ����������ϵ�ṹ������ϵͳ�ȵȡ�����Ȼ�Ͳ����йأ���Ҳ���Dz������еĶ�����


>>
>> > Jeffrey Zhao
>> > Blog:http://www.cnblogs.com/JeffreyZhao/
>> > Twitter:https://twitter.com/jeffz_cn
>>
>> > *From:* Guancheng Chen <chenguanch...@gmail.com>
>> > *Sent:* Monday, March 22, 2010 7:37 AM
>> > *To:* TopLanguage <pon...@googlegroups.com>

>> > *Subject:* [TL] {����}{���߳�}ʵʩ���б�̵�����ϰ�
>>
>> > ���ڿ���һƪ����Intel�ĺ�����˼�ķ������£������ᵽ������45�����ĸ���˾����Ա/��������/ս��ʦ����"ʲô��ʵʩ���б�̵������
>> > ��"ʱ������������ر��ἰ�Ĵ�����ࣺ��������(legacy code)������(education)������(tools)�����ں����ƵĿ־�
>> > (fear of many cores)�Լ���ά����(maintainability)��������Ȼ��һƪIntel
>> > Parallel
>> > Studio�����ģ����������ἰ��������ϰ�ȴ�dz�ֵ�����ۣ��������Ҷ�������ϰ���һЩ��dz������ϣ������һ����ש��������ã���ӭ��Ҹ������
>> > �Ŀ�����
>>
>> > ( ע������Google Group����ԭ�ĵ�һЩ�����Ӷ�ʧЧ�ˣ�������и�õ��Ķ����飬�뿴
>>
>> >http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...
>> > )
>>
>> > 1. ��������
>> > ������֪�����л�ʵʩ����������������ѹ�˾����Щ����������л���100K~1000K�Ĵ��������dz�����б�̱������Ƿdz����׳���ģ�
>> > һ�������data race, dependency, non-deterministic, memory consistency,
>> > dead lock, serialization bottleneck, thread safe�ȵ����������һ��������������ͷ�󣬸��˵Ҫ��
>> > Ч�ɿ��IJ��л���Щ�Ӵ�����������ˡ������ѵ��Ǻܶ��������뻹�б�д���Ѿ���ְ���ĵ�ע�Ͳ�ȫ�����⣬��������ѩ�ϼ�˪���ӳɱ��������������ͨ��һ
>> > Щ����ı�����(����Intel��ICC)�Զ����л�һЩ����������������ʡǮ�ģ��������ַ�������ȱ�ݾ�������Intel ICC�����Զ��ͱ�����
>> > ���Զ����л��Ĵ���dz��٣��Ӷ��������ṩ�������Ż��dz����ޣ����Ҿ����������ܻ��speedup�Ĵ���Ҳ�кܶ�Լ������(����loop��ѭ��֮��
>> > û��dependence�����Ҹ�loopӦ����һ�������ȵ�)������Ŀǰ����״���Ǵ������������벢������Ч�ı����л�������ҵ�ĽǶ��������������
>> > ��һ�ֽ���������ڶ�ʱ���ڿ��ٿɿ���ͨ��ʵʩ���л�������������10%~30%������������ô����Ѿ���Ϊ��˾��ʡ�����ɱ��ˡ�
>>
>> > 2. ����
>> > �ڶ�����ϰ����ܾ��dz���Աȱ�����б�̷���Ľ����ˡ���ʵ���б���Ѿ��ж���ʮ�����ʷ�ˣ������ڶ��CPU����֮ǰ��Щ���б�̶���"ר��"�ǵ���
>> > �ߡ���ʱ��IJ��б�̴������ڼ�Ⱥ�����ͻ���߷������ϣ�ͨ��MPI(message
>> > passing model)����SMP(�Գƶദ��������һ
>> > ���������ж������CPU������shared memory model)����ɲ��м��㡣Pthread��׼��1995�꽨���ģ�֮�������
>> > Windows���Win32 thread�������ֳ�����"����ָ��"������data parallelģ�͵�OpenMP(OpenMP 3.0��
>> > ����task parallel֧��)��task parallel�ı���Click��Intel��Intel Thread
>> > Building
>> > Block(task parallel)��Java 1.5��ʼ�Զ��߳��ṩ�Ϻõ�֧��(������Java
>> > Memory Model)����������
>> > GPU�ķ�չ��Nvidia�ֿ�ʼ��CUDA(data-parallel)��Appleһ�����ԣ����б���Ժ������������ҵò�һ�֣������Լ�����Ū
>> > �˸����CPU��GPU��ϱ�̵�OpenCL��΢��һ��Ҳ��ס��ҲҪ����Visual
>> > Studio2010��ʼ��C#�IJ��п⣬����C++0xҲ
>> > Ҫ������߳�֧�֣��������ϹŶ�ErlangҲ��Ϊ����֧�ֲ��б������ȳ�����֮����Ħ�����ڴ��������ʧЧ�����ҵ�綼��ʼ�������б�̷���
>> > չ��
>>
>> > ���ǶԳ���Ա��˵����ʲô����أ�������������ܵĽ���󶼻��Ǵ����������Щ�㷨����ݽṹ���ߵ�����һƪ��̸��˵"���ҿ����������������������
>> > ��Ӳ��������Ѿ��޼ƿ�ʩ�˵��µģ����ǽ�Moore����ʧЧ���������Ѹ���������ߣ������Ǹ����ǵĻ���ֻ����ijЩָ�������еø���˶��ѡ�������
>> > �̵��뷨��֤����ʧ�ܵģ���һ�㶼����е�����......����˵���ж��ٳ���Ա������δ��һƬ�����Ļ�������ǿ�ҵ���Ȥ���Ҽ���û����˵��������ǵ��߿ࡣ
>> > ��������ѧԺ��Щ��Ӳ���ļһ�һֱ�������������Ǵ��"���ɼ�Ӳ����չ��������ת��ֱ�ӵ��³���Ա����ѵ�����Ѿ������ˡ���ô����Ա�����ܵ����õ�
>> > ���б�̽������𣿺���Ȼ�����������һ����ͨ�ij���Ա��"����ò��б������ô��"��ʮ�а˾Ż�˵"�Ҿ��ú���"��ǰһ���������۷���������ö��߳�
>> > �û��Ƕ��̺ã���ʵ��ԭ����������¶��߳����������ƣ�����isolation�Ķ���ģʽ����programming productivity
>> > ��performance֮���ҵ��ȽϺõ����ԣ����Թ��ں��з����������߶�ѡ���˶���(�����Ʒ�)���Ӵ��������������������о���ϵ��ģ�����д
>> > OS/Compiler�ģ����Ƕ��������Եģ����ڶ��ڻ�Ŭ����Ϊ���ij���Ա�ṩһ��������ʹ�õIJ��б��ģ�ͣ�Intel�⼸�겻Ҳ�ڸ�����
>> > ѵô���ⶼ�Ǻ����󣬵��ǣ��������ȫ���б��ʱ�����൱����·Ҫ�ߡ������IT���������鵥��������в��б�̵��鼮���Ǹ��ܺõ�д�ա�
>>
>> > 3. ����
>> > ���������£���������������ô�ֽ׶��������õģ����Һ��õIJ��б�̹����ж����أ���ӭ��Ҳ��䣩��
>>
>> > (1) IDE: Intel Parallel Studio��΢�����ϳ�����VS2010��һ����Sun��Sun
>> > Studio(��֪�����δ����
>> > �Σ����������ͺ�С��)��Nvidia��CUDAƽ̨ʲô�ľ��Ȳ�����
>> > (2) Compiler: Intel��ICC(���Զ����л�һЩ����)��Nema Labs��FASThread(�����������Ľ���������ܿ���
>> > �ɿ���ָ������Աʵʩ���л�)
>> > (3) Performance Tuning: Intel Vtune Analyzer(�ۺ����ܷ���)��Thread
>> > profiler��
>> > Acumem��Thread Spotter(��Զ��Cache�����ܷ������Ż�)
>> > (4) Debugging: Petra��Jinx
>>
>> > �������Ҹ��˾������ǶԳ���Ա��˵ȷʵ���ã�����ǰ����������Ҫ���á�����ʵ�ָ�ڶ���"����"�кܴ��ϵ�ˡ�
>>
>> > 4. ���ں˵Ŀ־�
>> > �������ǿ���4���Ѿ��dz��ձ��ˣ��ȹ����ǿɾ���8�ˣ�16�ˣ�32���ˡ�����ȷ����Ĵ����ں������������������кܺõ����ܣ��ܺõĿ������ԣ���
>> > ����Ǹ����⡣�������������о����Ƕ��̳߳�������������ܷ�����Ŀ�ľ���Ϊ�˰������Ա��õĽ����������ɵ�����ƿ����ʵ���ϣ�Ϊ�˵õ��ܺõ�
>> > �������ԣ�����Ա��Ҫ������Ҫʹ�ò����Ѻõ���ݽṹ(����concurrent hash
>> > map)��ʹ��ϸ���ȵ������������̣����data
>> > parallel���㷨�����ܵ���(������͵�false sharing����)�ȵȵȵȣ�������ÿһ��Dz�С����ս����������һƪ���¶����
>> > ���̳߳����ṩ��һЩ���õĽ��顣
>>
>> > 5. ������
>> > �������ʣ�����ϣ���д����ܹ����ִ��runtimeϵͳ��buildϵͳ�Լ��������д���һ����ȷ�Ĺ��������Ǹ�ϣ����Щ���д���������⡢����ά
>> > �������нϳ����������ڡ������ֽ׶��������ղ��б�̵ij���Ա��֮���٣����Ҳ��б��������ô���ѣ����������Щ���д���ֻ����һЩСС�ĸĶ������п�
>> > �ܵ����µ�bug���µ�����ƿ�����������һ���dz�ʹ������顣


>>
>> > To unsubscribe from this group, send email to pongba+
>> > unsubscribegooglegroups.com or reply to this email with the words
>> > "REMOVE
>> > ME" as the subject.
>>
>> > To unsubscribe from this group, send email to pongba+
>> > unsubscribegooglegroups.com or reply to this email with the words
>> > "REMOVE
>> > ME" as the subject.
>>
>> --

>> Tinyfool�Ŀ����ռ�http://www.tinydust.net/dev/
>> �������http://www.codechina.org
>> myTwitter:http://twitter.com/tinyfool
>


> To unsubscribe from this group, send email to

> pongba+unsubscribegooglegroups.com or reply to this email with the words

Lai Jiangshan

unread,
Mar 22, 2010, 10:17:28 AM3/22/10
to pon...@googlegroups.com
由于内存/cache模型和编译器/cpu的优化, 并行化是不可能通过库来实现的.

我认为最大的障碍是支持并行化的语言.

2010/3/22 Guancheng Chen <chengu...@gmail.com>
1. C语言可以使用pthread等库实现并行化,C++ JAVA等已经会即将支持多线程 所以语言能实现并行化 只是难易问题
2. 是指Shared memory模型,多核共享一条内存总线所以造成带宽问题么?这确实是个问题,不过我感觉硬件商家会负责为你带来越来越多的带
宽,而程序员的任务只是合理的利用好这些给定的带宽
3. 能具体说说哪些误导宣传么?

On 3月22日, 上午1时46分, 陨落雕 <geo....@gmail.com> wrote:
> 呃,我想的障碍是: 1. 类C语言的统治地位; 2. 内存带宽不够; 3. 误导性宣传;

>
> On Mar 21, 7:37 pm, Guancheng Chen <chenguanch...@gmail.com> wrote:
>
>
>
> > 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> > 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> > (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> > Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> > 的看法。
>
> > ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...

Jeffrey Zhao

unread,
Mar 22, 2010, 10:38:33 AM3/22/10
to pon...@googlegroups.com
能详细说说为什么“由于内存/cache模型和编译器/cpu的优化, 并行化是不可能通过库来实现的”吗?

Jeffrey Zhao
Blog: http://www.cnblogs.com/JeffreyZhao/
Twitter: @jeffz_cn
Sent: Monday, March 22, 2010 10:17 PM

Guancheng Chen

unread,
Mar 22, 2010, 10:39:40 AM3/22/10
to TopLanguage
您值得是那篇著名的“Threads Cannot be Implemented as a Library”吧?恩,好用的并行语言确实关键,虽然
C++0x和Java都会加入memory model,但是要程序员来手动负责这些事情确实还是挺约束生产力的。

On 3月22日, 下午3时17分, Lai Jiangshan <eag0...@gmail.com> wrote:
> 由于内存/cache模型和编译器/cpu的优化, 并行化是不可能通过库来实现的.
>
> 我认为最大的障碍是支持并行化的语言.
>

> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>

Guancheng Chen

unread,
Mar 22, 2010, 10:40:37 AM3/22/10
to TopLanguage
主要就是那篇《Threads Cannot be Implemented as a Library》的论文,跟我以前发帖说的
Sequential Consistency,memory model有关

On 3月22日, 下午3时38分, "Jeffrey Zhao" <je...@live.com> wrote:
> 能详细说说为什么"由于内存/cache模型和编译器/cpu的优化, 并行化是不可能通过库来实现的"吗?
>
> Jeffrey Zhao
> Blog:http://www.cnblogs.com/JeffreyZhao/
> Twitter: @jeffz_cn
>
> From: Lai Jiangshan
> Sent: Monday, March 22, 2010 10:17 PM
> To: pon...@googlegroups.com
> Subject: Re: [TL] Re: {技术}{多线程}实施并行编程的五大障碍
>
> 由于内存/cache模型和编译器/cpu的优化, 并行化是不可能通过库来实现的.
>
> 我认为最大的障碍是支持并行化的语言.
>

> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>

Alleluia

unread,
Mar 22, 2010, 11:03:43 AM3/22/10
to TopLanguage
no no.其实Concurrency和Parallelism完全是两码事情,IO来区分它们其实完全是从最基本的体系结构上来说就是如此的.你把
IO理解为网络通信,磁盘读写就太狭隘了.
比如看这个图
http://ian--king.javaeye.com/upload/picture/pic/57449/40915ec8-f578-3398-9931-1afa4364a2b9.jpg
,我们要计算一个ax^2+bx+c的一元二次方程,左边的是并行计算,右边的是顺序计算.这两者完全就是两个体系结构,我们现在所使用的计算机是右边
那个图是由Control Flow Drive的.左边是Data Flow Drive的是典型的并行计算机的结构.其中最大的区别就是,右边的架
构采用了PC指针和Assignment.Assignment本身不是一个计算过程,仅仅是一次IO操作,从存储器里拿出数据/程序灌入运算器或者相
反.那么Assignment跟Concurrency有什么关系呢?为了响应Assigment这种基础的IO,那么冯结构必须依靠CPU时钟来驱动
PC指针的移动.因此控制流驱动模式构成了CPU响应外界IO的最基本的模式.无论是内存还是磁盘或者网络,CPU要获取外部设备的IO最基本模式,只
能是通过本地时钟触发控制流,周期性发起状态查询.CPU在某个周期向其他设备发送信号,在收到远端设备的反馈信号后计算得出本地代码序列上的程序段地
址,然后移动PC指针指向该地址进行处理。无论是早期的轮询模式还是现在广泛采用的中断方式,其基本的IO模式并没有改变,只不过查询对象由最初的IO
设备演变为中断寄存器.
因此你可以看到,Concurrency其实只是在讨论如何能够利用外设信号与CPU时钟之间的差异,让CPU在一定的时钟周期内尽可能多的响应不同外
设信号。一个通常的程序仅仅只需要通过Assigment响应内存IO,而Concurrency程序需要相应成千上万个外部设备,这仅仅是量上的区别
并没有到任何质上的区别,Concurrency程序本质上仍然是一个顺序执行的程序而已.采用恰当的技术比如完成端口之类的,可以在单核CPU机器上
仅仅采用单线程模型就能得到极高的并发性.当然多核同时处理可以进一步提高并发量,但是这不是必须的.
换一句话说,目前的CPU架构本身就是一种具备了Concurrency能力的顺序型架构.甚至在当初冯诺伊曼设计这个架构的时候,就极力杜绝并行计算
的指令在这种机器上出现在程序里,因为他认为并行执行的指令会让人发疯.而你再看右边的计算机构,与冯结构完全不同.他的计算是彻底并行的,这就是所谓
的数据流驱动.虽然说冯结构本身不利于并行,但是这个体系发展到现在,已经在不同层面上用冯结构模拟数据流计算.往小里说,CPU上最典型的顺序型程序
在微指令层面上有很大一部分就是数据流驱动并行执行的,因为要做OOO.往大了说,并行在若干个独立内核上的线程组之间的互相通信,也是一种数据流驱
动.并行必定是数据流驱动的.这是两者本质上的不同.如果你去看GPU上的并行就更接近这个模型,所有的计算都是分成若干个stage,数据依次从
stage上流过,stage上的并行计算单元对数据进行高密度的并行计算.这就是所谓的流处理器.当然现在的流处理器还是非常的简单,未来的GPU会
像Dataflow machine的方向发展.当然DataFlow machine也有自己的问题,比如说的指令牌粒度太小了,这导致两个重要缺
点,一个是通信代价非常高,另一个是指令牌点火代价很高。而Standford的ImagineGPU流处理器引擎可以看作介于数据流机和指令流机之间
的架构,所作的一个重要权衡就是增加指令牌的粒度,从而减小点火代价和利用赠大的Token粒度去减小通信代价

至于粒度问题,关键是看你的计算资源有多少.比如说CPU目前最多8核,16核.那么你所谓的按照循环来进行并行自然是可行的,但是你放到CUDA上
去,GTX295有250个内核,你为了让他所有的内核处于工作繁忙的状态,就根本不可能按照循环层次来进行并行,在这个上面并行的粒度是需要划分的极
为纤细的。更诡异的是有些算法,处理的数据量很小,但是计算量可能极为庞大.比如一些运动估计算法,在一个16*16的像素区域内要完成256×256
次sad运算.这种数据量和计算完全非常不成比例的.怎么对并行粒度的进行有效的划分,非常考算法功夫的.并行计算最好是通过算法杜绝锁,这也是非常困
难的地方.

> > > > > On 3月22日, 上午2时20分, Tinyfool <tinyf...@gmail.com> wrote:
>
> > > > > > 唉,本来不想广告的,既然赵姐夫都冒出来了,我也来广告一下
>
> > > > > > Mac OS X最新的并行机制叫做GCD,靠,听名字就知道无比强大了吧?
>
> > > > > > 还有支持显卡计算的OpenCL也是无比强大啊。
>
> > > > > > 2010/3/22 Jeffrey Zhao <je...@live.com>
>
> > > > > > > 我来做广告:有了并行库、或是F#这种语言的支持,并行编程已经容易很多了。开发效率,执行效率,可维护性都可以有显著提高。
>
> > > > > > > 其实还是"抽象"这个万能武器的作用,只要有牛人把容易出问题的东西隐藏起来,封装起来,给一个好用的抽象,对大部分程序员来说就能美好许多。
>
> > > > > > > 例如Memory Consistency,让JVM或CLR那样在各CPU架构中统一起来,即便是没有并行库的支持,写并行程序已经可以轻松很多了。
>
> > > > > > > 至于教育上......我觉得其实这个问题倒不是并行特有的,也不是并行上面表现的更彻底,而是(国内)本来就没多少人被教育好。
>
> > > > > > > 例如计算机体系结构,操作系统等等。这虽然和并行有关,但也不是并行特有的东西。
>

> > > > > > > Jeffrey Zhao
> > > > > > > Blog:http://www.cnblogs.com/JeffreyZhao/

> > > > > > > Twitter:https://twitter.com/jeffz_cn
>
> > > > > > > *From:* Guancheng Chen <chenguanch...@gmail.com>
> > > > > > > *Sent:* Monday, March 22, 2010 7:37 AM
> > > > > > > *To:* TopLanguage <pon...@googlegroups.com>

> > > > > > > *Subject:* [TL] {技术}{多线程}实施并行编程的五大障碍


>
> > > > > > > 近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问"什么是实施并行编程的最大障
> > > > > > > 碍"时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧
> > > > > > > (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel
> > > > > > > Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们
> > > > > > > 的看法。
>
> > > > > > > ( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看
>
> > > > > > >http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-...
> > > > > > > )
>
> > > > > > > 1. 遗留代码
> > > > > > > 众所周知,并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常,而并行编程本身又是非常容易出错的,
> > > > > > > 一大堆诸如data race, dependency, non-deterministic, memory consistency,
> > > > > > > dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大,更别说要高
> > > > > > > 效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职,文档注释不全等问题,这无疑是雪上加霜。从成本上来讲,如果能通过一
> > > > > > > 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的,但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器
> > > > > > > 能自动并行化的代码非常少,从而导致它能提供的性能优化非常有限,而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间
>

> ...
>
> 阅读更多 >>

Alleluia

unread,
Mar 22, 2010, 11:35:25 AM3/22/10
to TopLanguage
且抛开,流处理器这种异构的内核,SMP和Numa之间的差异.就说说单个CPU上做SIMD并行化的需要考虑的内存/cache问题.
比如作矩阵乘法运算,如果矩阵都是按照行存储, 则在A*B中, 乘法对B的访问是按列的. 假设B一行有N个元素, 那么在存储器中, 两个同列不同
行的元素所在的存储单元相差N. 对B的访问并不是局部化的. 因为访问不局部化, 所以每次乘法, 都需要从内存中调一个 cache 单元到
CPU. 这个极大的降低了处理器的执行速度. 因此, 矩阵乘法的优化的核心, 在于局部化B的访问. 反过来, 如果矩阵按照列存储, 则要局部化
对A的访问. 关于怎样局部化访问还能获得正确的乘法,那就要针对具体的情况设计正确的算法.
为何并行化不可能用库来实现呢?其实问题根源在于,并行颗粒度的变化,导致对IO,算法的乃至硬件结构产生天差地别的变化.一个顺序型的问题,可以划分
成不同的颗粒度.比如说一个100M的Byte型数组,要求和,你可以按照1M的颗粒度进行划分,也可以按照1K,甚至256,128,乃至
4byte,8byte进行划分.每种划分,产生的数据搬运的次数,每次数据搬运的大小,乃至缓存命中率都是不同。
再进一步说,颗粒度划分的越细,意味着计算单元就需要增加,否则就没有意义.但是一旦运算单元的增加到一个的极限,就会引起硬件结构的改变,比如说
SMP根本无法支撑超过16Core的架构,超过这个限度你就得换Nehalem那种Numa架构.在Numa结构下你就不得不考虑,本地内存和远端内
存的区别。
目前没有一个很好的方案来统一不同等级并行计算的架构,在8核之下你用Numa就是杀鸡用牛刀了,而超过32核Numa也不堪重负需要像GPU那样去设
计硬件架构这也就是为什么Intel的Larrebe会难产的原因.每个X86内核都要顶着一个硕大的Deocder还有branch
prediction,OOO之类的庞然大物,用PII来做Larrebe都非常的头大的事情.所以,我个人认为,并行化本身就是和硬件结构极为相关的
事情,这一切都不太可能由一个统一的计算库来完成统一的封装.

On 3月22日, 下午10时38分, "Jeffrey Zhao" <je...@live.com> wrote:
> 能详细说说为什么"由于内存/cache模型和编译器/cpu的优化, 并行化是不可能通过库来实现的"吗?
>
> Jeffrey Zhao
> Blog:http://www.cnblogs.com/JeffreyZhao/
> Twitter: @jeffz_cn
>
> From: Lai Jiangshan
> Sent: Monday, March 22, 2010 10:17 PM
> To: pon...@googlegroups.com
> Subject: Re: [TL] Re: {技术}{多线程}实施并行编程的五大障碍
>
> 由于内存/cache模型和编译器/cpu的优化, 并行化是不可能通过库来实现的.
>
> 我认为最大的障碍是支持并行化的语言.
>

> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>

Kula

unread,
Mar 22, 2010, 11:39:25 AM3/22/10
to pon...@googlegroups.com
我对这个比较感兴趣,能详细介绍一下golang在多核下的表现吗?

2010/3/22 Googol Lee <goog...@gmail.com>
> myTwitter:http://twitter.com/tinyfool

To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Guancheng Chen

unread,
Mar 22, 2010, 12:14:12 PM3/22/10
to TopLanguage
您说的可能跟那个问题不是一回事情,窃以为Lai Jiangshan所说的是指CPU和编译器会对并行程序做违反程序semantics的优化(例如
reordering),导致破坏Memory Consistency,例如大牛HJ Boehm的一篇论文《Threads Cannot be
Implemented as a Library》,我之前也写过一篇浅显小文:http://www.parallellabs.com/
2010/03/06/why-should-programmer-care-about-sequential-consistency-
rather-than-cache-coherence/

另外对于您的Concurrency和Parallelism的看法,我大致理解了您所指的"Concurrency"的含义,它跟我所认为的软件层面
的Concurrency不太一样,您的含义更宏观一些,但是感觉我还没有抓住它的精要,不知道能否推荐几篇文献供我参考?

> > > > (4) Debugging: Petra的Jinx...
>
> 阅读更多 >>

windstorm

unread,
Mar 22, 2010, 1:18:43 PM3/22/10
to pon...@googlegroups.com
实在是不能同意你更多......很早很早以前我就在这里和人争论过,GPU的并行计算平台不可能一统天下的。CUDA也不是救世主。OpenCL更不是。


----------------------------------------------------------------------------------
Yours Sincerely
Kun

www.kunli.info
http://twitter.com/cnbuff


2010/3/22 Alleluia <allu...@gmail.com>:

> To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
>

juv...@gmail.com

unread,
Mar 22, 2010, 4:14:12 PM3/22/10
to TopLanguage
好像大家说的concurrency和parallelism不是一个东西?

windstorm

unread,
Mar 22, 2010, 4:32:37 PM3/22/10
to pon...@googlegroups.com
我觉得这两个东西,sun的多线程编程手册说得很清楚了,没必要重新定义。

Parallelism is a condition that arises when at least two threads are
executing simultaneously, while concurrency is a condition that exists
when at least two threads are making progress.

也就是说concurrency有点像更通用化,限制条件更低的parallelism,而某些case下两者完全不同。比如单核多线程程序,你可以叫它是concurrent
program,但不能叫它是parallel
program。Concurrency在现有体系的处理器架构下都可以做到。和Alleluia说的一样,只是一个时钟周期同步的问题。写过硬件编程的人,几乎都算是写过concurrent
program,但很少写过parallel program

----------------------------------------------------------------------------------
Yours Sincerely
Kun

www.kunli.info
http://twitter.com/cnbuff


2010/3/22 Juv...@gmail.com <juv...@gmail.com>:
> 好像大家说的concurrency和parallelism不是一个东西?

Guancheng Chen

unread,
Mar 22, 2010, 5:02:31 PM3/22/10