{技术}{多线程}实施并行编程的五大障碍
Guancheng Chen
碍”时，下面五个因素被提及的次数最多：遗留代码(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
To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
陨落雕
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
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
2. 是指Shared memory模型，多核共享一条内存总线所以造成带宽问题么？这确实是个问题，不过我感觉硬件商家会负责为你带来越来越多的带
宽，而程序员的任务只是合理的利用好这些给定的带宽
3. 能具体说说哪些误导宣传么？
Jeffrey Zhao
Tinyfool
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
陨落雕
2. 就是这个问题，可惜从来都没跟上来过，光传输是一个可行性，如果实现了的确会改变现在的处境；
3. 说在shared memory模型上内核数量可以无限上去的误导宣传，可惜这个20年前就失败，现在在TOP500上能看到的
supercomputer都是distributed memory model；
陨落雕
题（每个小的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
Tinyfool
woo
陨落雕
> ...
>
> read more >>
Jeffrey Zhao
Changsheng Jiang
Milo Yip
但怕買了Fermi後，機器也只是用來做做翻譯……
--
Milo Yip
Twitter @miloyip
http://www.cnblogs.com/miloyip/
http://miloyip.seezone.net/
Milo Yip
archer
陨落雕
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
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
Guancheng Chen
通用并行计算平台的重要性，而为了保证最大的商业利益就选择自己重新搞一个新标准而不是跟当时已有CUDA的Nvidia合作，结果现在NV也开始支持
OpenCL，但是他们最新的一本教材里说到"根据我们的经验，学习OpenCL最好的办法是先学CUDA"
> > >>> 4. 对众核的恐惧...
>
> 阅读更多 >>
Guancheng Chen
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
好？
On 3月22日, 上午6时48分, Kula <kulas...@gmail.com> wrote:
> 我觉得 想要并行开发 必须绕开c/c++
>
> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>
> > > parallel的算法，性能调优(例如典型的false...
>
> 阅读更多 >>
Guancheng Chen
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
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
我还以为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
Guancheng Chen
考虑实施并行化？
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
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
让一群有经验的专家来实现一套通用库或者语言来提供一个基本的编程框架.而在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
至是指数增加的.一个文本长度增加一倍,数据量也就增加一倍.而一张图片,长宽增加一倍,数据量要增加四倍.一个既有的算法在没有大的理论突破的前提
下,在特定的硬件平台上能够优化加速5-6倍已经是了不得了.但是对于多媒体数据来说,这个加速真的不算什么.一个算法在720p上快3,4倍,换到
1080p的也就是达到了720p上不加速的效果而已.
Guancheng Chen
合并行的算法那简直就是巧妇难为无米之炊。但是有疑问的一点是关于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
单纯。他更多的是一种类似时钟同步的问题,如果你把IO事件想像成一种时钟信号.其实时钟本来也就是一堆信号而已.如果你做过Circuit 的东西就
会明白,IO只是在不同的时序下进行数据采样.比如最简单的同步时钟,所有的时序电路公用一个时钟,把不同的电路安排在不同的时序边沿上触发.当然更复
杂异步逻辑的道理也是一样的.放到宏观的Concurrency的问题的实质并没有多大改变,只不过CPU依靠PC指针的移动把这种电路上的时序处理软
件化了.
而Parallelism更多的是需要考虑计算问题同时还要兼顾IO.Parallelism首先要回答的是一个东西是不是可并行的.回答完这个问题
后,如果可并行那么在什么样的硬件设备上并行是最合适的这样一个问题.在Parallelism中需要考虑的的IO也不仅仅是来自于网络更多是,缓存,
内存,磁盘,总线等等.其实我觉得,在Parallelism下你总是处于一个矛盾状态,颗粒度越小的并行获得的计算资源的利用率也就越大加速比就越
大,但是同时通信系统的工作也就越是繁忙整个运算过程浪费在通信消耗上的时间也就越多.
这个当中的tradeoff是非常困难的.很多时候速度不快,完全不是因为你的核心不够多,而是你的通信速度不够高.
> ...
>
> 阅读更多 >>
Alleluia
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
从广义上来讲Parallelism和Concurrency是基本重合的两个概念，只不过可能Concurrency稍微偏工程一点，
Parallelism稍微偏研究一点。例如Herb Sutter要出的新书叫Effective Concurrency,而市面上其他讲并行计算
的书不少也使用Parallel相关的词汇。
另外您这句话我有些不赞同："颗粒度越小的并行获得的计算资源的利用率也就越大加速比就越大"，拿一个计算密集型的嵌套循环举例，对比并行外层循环和并
行内层循环，无疑你在并行化外层循环时的性能加速比更好，而这时候你的并行度是粗粒度的(内循环并行相对来说是细粒度的)。当然，粗/细粒度的选择确实
是个tradeoff，拿锁竞争来说，细粒度的锁意味着更好的Scalability，但是你加锁/解锁的次数相比组粒度所来说增加了，而这种加锁/解
锁的操作是有开销的，所以需要在锁操作本身的开销和程序的Scalability中做一个平衡。
多谢指教！
> > > > > > 了个针对CPU和GPU混合编程的OpenCL，微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库，马上C++0x也...
>
> 阅读更多 >>
Googol Lee
不过golang在cpu密集的并发上不知道效果会怎么样，就现在的表现来看比erlang好，但还赶不上c/c++
Jeffrey Zhao
���������ڴ���Ժ�ڲ��������Ͻ���F#�ƹ㣬������
Jeffrey Zhao
Blog: http://www.cnblogs.com/JeffreyZhao/
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
我认为最大的障碍是支持并行化的语言.
1. C语言可以使用pthread等库实现并行化，C++ JAVA等已经会即将支持多线程 所以语言能实现并行化 只是难易问题
2. 是指Shared memory模型，多核共享一条内存总线所以造成带宽问题么？这确实是个问题，不过我感觉硬件商家会负责为你带来越来越多的带
宽，而程序员的任务只是合理的利用好这些给定的带宽
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
Guancheng Chen
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
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
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
比如作矩阵乘法运算,如果矩阵都是按照行存储, 则在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
> 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
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
----------------------------------------------------------------------------------
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
windstorm
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
同架构需要做不同优化等。CPU的性能是latency-oriented，GPU是throughput-oriented,Intel的
Larrabee虽然现在来看不成功，但是业界都在朝着那个方向努力。
On 3月22日, 下午6时18分, windstorm <likunarmstr...@gmail.com> wrote:
> 实在是不能同意你更多......很早很早以前我就在这里和人争论过，GPU的并行计算平台不可能一统天下的。CUDA也不是救世主。OpenCL更不是。
>
> --------------------------------------------------------------------------- -------
> Yours Sincerely
> Kun
>
> www.kunli.infohttp://twitter.com/cnbuff
>
> 2010/3/22 Alleluia <allul...@gmail.com>:
> >> > > 工欲善其事，必先利其器。那么现阶段我们能用的，并且好用的并行编程工具有多少呢（欢迎大家补充）？...
>
> 阅读更多 >>
windstorm
OPENCL还是主要面向multimedia吧，CUDA/OpenCL在业界代表了流处理的方向，从GPU针对任务的角度讲是好的。其他的就算了。就像Alleluia说的那样，在硬件架构没有更多的突破之前，不说没有生命力，至少想取得任何进一步的突破都太难。
现在这个领域，你吹你的水，我吹我的水。至于谁的泡泡大，我看不清。所以真要选东西学，最好还是针对自己的application选靠谱。这也是并行编程教育难的问题。大家需求完全不一样。
----------------------------------------------------------------------------------
Yours Sincerely
Kun
www.kunli.info
http://twitter.com/cnbuff
2010/3/22 Guancheng Chen <chengu...@gmail.com>:
Alleluia
process,也可以不用.一个单核单线程的Concurrency程序只要写的好,对于几万个并发连接不是问题.但是Parallelism必须要
用到multithread.对于Concurrency来说,multithread只是一种可选的方案.
当然,在CPU架构上Concurrency和Parallelism的很多设施都是可以复用的,比如高性能的线程池,以及细粒度的锁等等.
On 3月23日, 上午4时32分, windstorm <likunarmstr...@gmail.com> wrote:
> 我觉得这两个东西，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下两者完全不同。比如单核多线程程序，你可以叫它是co ncurrent
> program，但不能叫它是parallel
> program。Concurrency在现有体系的处理器架构下都可以做到。和Alleluia说的一样，只是一个时钟周期同步的问题。写过硬件编程的人，几 乎都算是写过concurrent
> program，但很少写过parallel program
>
> --------------------------------------------------------------------------- -------
> Yours Sincerely
> Kun
>
> www.kunli.infohttp://twitter.com/cnbuff
Alleluia
PCIE2的bus带宽太窄了.在上面来回传递一次几M的内存可能需要化掉500us左右.如果一个算法本来就是在3-4ms级别的,你要用GPU去优
化,内存带宽的消耗就占了1/10,这是非常可怕的事情.或许像AMD那种Fusion架构是一种趋势,但是目前来说没有太大的进展.貌似AMD出了一
款混合的CPU,但是貌似还没有看到有多大的优势.
>
> 阅读更多 >>
Guancheng Chen
现在我在跟瑞典这边的爱立信合作做毕设 不过对象不是他们的Erlang 而是传统的C/C++程序 下半年可能我也去搞GPGPU了 因为它的
data parallel模型对遗留代码的并行化很有搞头，现在我粗略的想法是把Compute sensitive的任务放一部分到GPU上去做，
当然我也对GPU目前的一些限制有所了解 但是一些探索工作还是非常值得的 到时候还想向前辈多多请教
> > > >> > > 程的想法被证明是失败的，我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣？我几乎没有听说过，除了他们的诉苦。...
>
> 阅读更多 >>
Guancheng Chen
题。
On 3月22日, 下午10时41分, windstorm <likunarmstr...@gmail.com> wrote:
> Larrabee当初我还是很看好的，它的架构比其他的更像一个统一的方案，可惜后来Intel自己经验不足搞不好。
>
> OPENCL还是主要面向multimedia吧，CUDA/OpenCL在业界代表了流处理的方向，从GPU针对任务的角度讲是好的。其他的就算了。就像Al leluia说的那样，在硬件架构没有更多的突破之前，不说没有生命力，至少想取得任何进一步的突破都太难。
>
> 现在这个领域，你吹你的水，我吹我的水。至于谁的泡泡大，我看不清。所以真要选东西学，最好还是针对自己的application选靠谱。这也是并行编程教育难 的问题。大家需求完全不一样。
>
> --------------------------------------------------------------------------- -------
> Yours Sincerely
> Kun
>
> www.kunli.infohttp://twitter.com/cnbuff
>
> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>:
> >> >> > > 于硬件设计者已经无计可施了导致的，他们将Moore定律失效的责任推脱给软件开发者，而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线...
>
> 阅读更多 >>
windstorm
我个人倾向于等待一个比较好的统一性架构。两条路：
一是某一个全新概念的提出，这个要看学术界的努力，而且在某种意义上讲，学术界搞出一个真正可行的并行架构的可能性比工业界更高。虽说今天多核的发展是工业界引领的，但是点子还是最早学术界提出的。典型的有几个：斯坦福的Hydra（1996），斯坦福的Imagine(2000)，MIT的RAW（2002），以及UT奥斯丁的TRIPS（2003）。在这个问题上，是不得不佩服美国的创造力，要知道直到在2000年左右，所有的人都还在为处理器频率按照摩尔定律翻翻而狂热，美国的顶尖研究员就早已看到了这条路的尽头并指出未来处理器的发展之路。
二是你用现有的架构，但是application引导。如果要找一个面向多application
domain的话，刚才说了，本来看好Larrabee，因为它的架构解决了CUDA一个很大的潜在问题，而且允许现有程序员不经过任何特殊training就上手编程，包括图形图像，科学计算，或者网络处理，各个领域。
不过可能就是因为这个solution的过于理想化导致结构的过于复杂化，才让其目前暂时流产。
总的来说，现在的问题就是软件发展不成熟，硬件发展不完善，你没法靠程序员决定使用什么并行技术，完全靠应用主导，这套技术在这个应用上如鱼得水，在那个应用上完全不罩，作为程序员，有什么办法？
----------------------------------------------------------------------------------
Yours Sincerely
Kun
www.kunli.info
http://twitter.com/cnbuff
2010/3/22 Guancheng Chen <chengu...@gmail.com>:
Guancheng Chen
第二点其实我就是指程序员根据他自己的程序领域选择合适的并行技术。Top Language真是藏龙卧虎啊。你是在Boulder么?我一个大学女同
学在你那读MIS的phd
On 3月23日, 上午12时04分, windstorm <likunarmstr...@gmail.com> wrote:
> 全民并行编程的时代，只有在全民能够并行编程的时候才会到来嘛，现在不是这个时候
>
> 我个人倾向于等待一个比较好的统一性架构。两条路：
>
> 一是某一个全新概念的提出，这个要看学术界的努力，而且在某种意义上讲，学术界搞出一个真正可行的并行架构的可能性比工业界更高。虽说今天多核的发展是工业界引 领的，但是点子还是最早学术界提出的。典型的有几个：斯坦福的Hydra（1996），斯坦福的Imagine(2000)，MIT的RAW（2002），以及 UT奥斯丁的TRIPS（2003）。在这个问题上，是不得不佩服美国的创造力，要知道直到在2000年左右，所有的人都还在为处理器频率按照摩尔定律翻翻而狂 热，美国的顶尖研究员就早已看到了这条路的尽头并指出未来处理器的发展之路。
>
> 二是你用现有的架构，但是application引导。如果要找一个面向多application
> domain的话，刚才说了，本来看好Larrabee，因为它的架构解决了CUDA一个很大的潜在问题，而且允许现有程序员不经过任何特殊training就 上手编程，包括图形图像，科学计算，或者网络处理，各个领域。
>
> 不过可能就是因为这个solution的过于理想化导致结构的过于复杂化，才让其目前暂时流产。
>
> 总的来说，现在的问题就是软件发展不成熟，硬件发展不完善，你没法靠程序员决定使用什么并行技术，完全靠应用主导，这套技术在这个应用上如鱼得水，在那个应用上 完全不罩，作为程序员，有什么办法？
>
> >> >> >> > > 些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的，但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器...
>
> 阅读更多 >>
Alleluia
法.没有这两样,几乎写不出什么高效率的并行程序.当然你的需求只是并行化循环这种简单的东西当然可以里例外.呵呵.
我觉得你最好放弃用GPGPU去搞遗留代码的想法.现在市面上的GPU产品无论是A记的还是N记的其编程架构与CPU完全不同,你不要想把一个循环简单
的porting到GPU上就能并行了.那是几乎不可能的,比如最简单的你如何处理branch?如果branch非常多,divergence会把速
度拖得比CPU版本还慢.你如何处理CPU代码里的数组随机访问,在GPU上无论是片上的还是片外的内存是不能随机访问的,最要命的是没有cache,
随机访问的代价极其高昂.你几乎需要把CPU上的代码面目全非地从新写一遍,遗留代码除了用作调试测试做结果比对之外几乎要全部抛弃.
> ...
>
> 阅读更多 >>
Alleluia
一捆Arm棒在一起都比PII靠谱.
On 3月23日, 上午5时41分, windstorm <likunarmstr...@gmail.com> wrote:
> Larrabee当初我还是很看好的，它的架构比其他的更像一个统一的方案，可惜后来Intel自己经验不足搞不好。
>
> OPENCL还是主要面向multimedia吧，CUDA/OpenCL在业界代表了流处理的方向，从GPU针对任务的角度讲是好的。其他的就算了。就像Al leluia说的那样，在硬件架构没有更多的突破之前，不说没有生命力，至少想取得任何进一步的突破都太难。
>
> 现在这个领域，你吹你的水，我吹我的水。至于谁的泡泡大，我看不清。所以真要选东西学，最好还是针对自己的application选靠谱。这也是并行编程教育难 的问题。大家需求完全不一样。
>
> --------------------------------------------------------------------------- -------
> Yours Sincerely
> Kun
>
> www.kunli.infohttp://twitter.com/cnbuff
>
> 2010/3/22 Guancheng Chen <chenguanch...@gmail.com>:
> ...
>
> 阅读更多 >>
windstorm
而且我看好它，并不是它将来会一统天下，而是说它相对革命性的架构部分程度上满足了线程完备，从而扩展了GPU的使用领域，所以我看好以它为代表的这种架构的发展。同类型的还有Sun当年的Rock和Niagara
1/2
----------------------------------------------------------------------------------
Yours Sincerely
Kun
www.kunli.info
http://twitter.com/cnbuff
2010/3/22 Alleluia <allu...@gmail.com>:
windstorm
----------------------------------------------------------------------------------
Yours Sincerely
Kun
www.kunli.info
http://twitter.com/cnbuff
2010/3/22 Guancheng Chen <chengu...@gmail.com>:
SevenCat
qiaojie
比较赞同Alleluia同学的观点。Parallelism真正的难点不在于我的程序能不能并行，而在于并行了之后性能是否得以提升。
用Parallel的唯一目的是为了得到更好的性能，如果一个程序用串行算法就可以达到性能要求，改成并行除了浪费CPU之
外并无实际意义。而要通过并行算法得到令人满意的加速比是非常困难的事情。举一个现实中的例子做类比：在人月神话
一书中指出向一个将要延期的项目中盲目增加人手，不但不能按时交付，反而可能更加延长项目的交付。这个例子告诉我
们，一项任务的完成时间跟所用的人手并不成简单的线性关系，如果任务分解不当，人多反而帮倒忙，这个道理同样适用
于并行算法。
把一个串行算法改成并行算法，首先要看并行度，不是所有的部分都可以并行的，有些部分只能串行归并，只有那些并行的
部分才可以被多核加速，并行度对于多核的加速效果有着决定性作用，假设一个并行算法有90%的并行度，那么他在8核CPU
上得到的加速比就是1 / (0.9/8+0.1) = 4.7倍，而在100核上的加速比降低到了1 / (0.9/100+0.1) = 5.26倍，所以说在多核上要得
到线性加速比是非常困难的，这个只是理想情况，并行化之后还会引入其他的overhead，另外目前的内存属于串行化访问的IO
设备，这在多核系统中将很容易成为瓶颈。所以在GPU上为了解决这个问题设置了多组内存Bank、加大位宽等方法来实施并行
化的内存访问，但是这也只能部分解决带宽问题，还是会碰上Bank Conflict以及访问合并等问题，制约了GPU的scatter/gather
能力。
有些同学提到用FPL来解决并行化问题，我觉得是过于乐观了，FPL在学术界研究了几十年了，如果能解决并行化问题那早就解
决了，轮不到我们再去担心这个问题。FPL最大的问题，它是面向软件的抽象，而不是面向硬件的抽象。而并行化是为了解决性
能问题，所以面向硬件体系架构是必须的，所以纵使你FPL能很容易的写出并行化的程序，但是执行速度比串行化的C代码还慢，
那要并行化有何用？
Guancheng Chen
码也可以用他们的技术。我之所以要提到遗留代码，是因为如果针对只对遗留代码的循环进行并行化就已经能取得比较可观的speedup(如果本身该循环是
热点，经过一些指导被程序员正确改成independent的之后即可并行化)，同时又不会引入太多的并行编程的复杂度。我原来测试它的时候一般1-3
个小时就能出结果，speedup在1.2~1.6之间(dual core, quad core 2.X)。
另外想请教您的实际工作中一般适用什么样的并行算法？任务分解(如TBB)？还是数据分解？
> > > > > >> > > 2. 教育...
>
> 阅读更多 >>
Guancheng Chen
On 3月23日, 上午3时37分, windstorm <likunarmstr...@gmail.com> wrote:
> 女生？LJJ？
> >> >> >> >> > > 众所周知，并行化实施最大的困难在于怎样把公司的那些遗留代码给并行化。100K~1000K的代码量都非常正常，而并行编程本身又是非常容易出错的，...
>
> 阅读更多 >>
Guancheng Chen
qiaojie
Guancheng Chen
On 3月23日, 上午10时43分, qiaojie <qiao...@gmail.com> wrote:
> 目前正在写的是一个软件渲染器，采用了光栅化和光线跟踪混合算法，渲染算法已经完全并行化了，
> 在4核系统上基本可以达到线性加速比，更多核的系统暂时还没测试。kd-tree的构造暂时还没有并
> 行化，以后有空了再研究。
>
> 2010/3/23 Guancheng Chen <chenguanch...@gmail.com>
莫华枫
qiaojie
To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
机械唯物主义 : linjunhalida
加上本地终端，运行一些本地进程，比如GUI，实时视频采集和分析什么的。CPU＋GPU。
根据需求和成本来考虑程序在本地或者数据中心。
其实好像这就是现在的状况？
未来的状况还是要局限于成本和性能，
如果瓶颈在数据传输，那么中心化趋势会很明显。
如果瓶颈在运算，那么程序员要花很多时间在并行处理上。
Hongzhang Liu
qiaojie
junyi sun
To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Hongzhang Liu
qiaojie
Guancheng Chen
On 3月24日, 下午12时36分, qiaojie <qiao...@gmail.com> wrote:
> 并行计算本来就是曲高和寡的东西，就跟3D渲染一样，能开发引擎的毕竟只是小部分人，大多数人在引擎的基础上做应用。关键在于是否有杀手应用，只要有大量的需求 ，自然会有人去做开发。
>
> 2010/3/24 Hongzhang Liu <hongzhang....@gmail.com>
>
>
>
> > 异构平台从网络处理器算起已经快10年了，现在情况仍然不明朗。就我看到的，异构平台要想高效，就必须向程序员暴露非常多的硬件细节，这必然导致编程的复杂性。 曲高和寡，要想渗透到应用程序这一块，我觉得很难。
>
> > 2010/3/24 qiaojie <qiao...@gmail.com>
>
> >> 说的没错，cell已经成了先烈了。不过这不代表异构的方向不对，CUDA，OpenCL也都是异构平台，以后我们会越来越习惯异构平台的。
>
> >> 2010/3/24 Hongzhang Liu <hongzhang....@gmail.com>
>
> >> 异构平台如果编程复杂度降不下来的话很难流行起来。cell已经死了...
>
> >>> 2010/3/24 qiaojie <qiao...@gmail.com>
>
> >>>> 不是所有的程序都需要并行化的，能用串行化解决的问题没必要并行，所以即使将来many-core系统成为主流，大部分程序员也没必要去搞并行计算。
> >>>> 我觉得未来的主流应该是类似cell这样一颗全功能核心带众多协处理核心的异构系统，这样才能达到最优的 性能/核心面积比。
>
> >>>> 2010/3/24 Guancheng Chen <chenguanch...@gmail.com>
qiaojie
To unsubscribe from this group, send email to pongba+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
机械唯物主义 : linjunhalida
产能=消费，产能才是主动力。技术成长是随着产能成长而起来的。
而产能多的结果就是满足了需求，造成一种需求带来技术进步的假像。
而技术和产能之间的关系又错综复杂。。
qiaojie
机械唯物主义 : linjunhalida
产出的东西没有价值，这样的活动就不能说是生产。
比如我这个程序员，花了1周写了一个垃圾程序，然后被开除了。
然后1个月闲着，这是我产能过剩吗？
而闲着的原因是政府给我失业金，我就不需要工作闲起来了。。。
机械唯物主义 : linjunhalida
在不同的场景下，可以采用不同的方式进行。
重要的是能够“又好又快”地实现需求，以及根据场景，把一个需求进行实现方式的伸缩。
不过看起来这样的工作还是要靠程序员来实现？而体系架构设计者要根据对应问题的本质特性来设计架构？
qiaojie
郝培强 tinyfool
机械唯物主义 : linjunhalida
qiaojie
机械唯物主义 : linjunhalida
qiaojie
郝培强 tinyfool
机械唯物主义 : linjunhalida
居振梁
qiaojie
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
fxc...@gmail.com
既然大家都说tools是concurrent的一个大issue。那不妨看看MS的Concurrency工具包：Parallel
Debugger/Parallel Profiler. 在下一个版本VS里面会加入Static Analysis的support。
msdn.microsoft.com/en-us/concurrency/default.aspx
On Mar 24, 9:04 am, 莫华枫 <longshank...@gmail.com> wrote:
> 凑个热闹，也来个广告：CERL 2.0初具雏形。
>
> --
> 反者道之动，弱者道之用
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/
> wave开通
AWu
感觉并行需要有足够简单，足够可靠的工程实施方法才能够大规模得被应用～
毕竟IT业从业人员不是所有人都足够聪明能够写得了、分析得了并行
一个可靠的工程方法来规避并行可能引发的性能或者功能缺陷，如果能够抽象到库里面规避当然更好，但是库这个东西得有足够多的工程实践才能做得出来吧，所
以我认为第一步是有一个可行的并行工程实施方法。
On 3月22日, 下午2时06分, Guancheng Chen <chenguanch...@gmail.com> wrote:
> 我还以为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定律失效的责任推脱给软件开发者，而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线
> > > 程的想法被证明是失败的，我一点都不会感到惊讶......你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣？我几乎没有听说过，除了他们的诉苦。
> > > 尽管我们学院那些搞硬件的家伙一直想让我相信我是错的"，可见硬件发展被迫向多核转移直接导致程序员们免费的午餐已经结束了。那么程序员现在受到良好的
> > > 并行编程教育了吗？很显然，现在随便问一个普通的程序员："你觉得并行编程容易么？"，十有八九会说"我觉得很难"。前一阵有人讨论服务器编程用多线程
> > > 好还是多进程好？其实根本原因就在于哪怕多线程有性能优势，可是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，新的性能瓶颈，那真的是一件非常痛苦的事情。
>
> > > 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