{OT}{多核时代}第三次软件危机
Guancheng Chen
become several orders of magnitude more powerful! To put it quite
bluntly: as long as there were no machines, programming was no problem
at all; when we had a few weak computers, programming became a mild
problem, and now we have gigantic computers, programming has become an
equally gigantic problem.
造成软件危机的主要原因是因为计算机的计算能力正在呈指数级地增长！说的简单些：在没有计算机的时候，编程根本就不是一个问题；当一些计算能力较弱的计
算机出现时，编程成了一个中等难度的问题，而现在，我们拥有了计算能力超绝的计算机，编程就变为了一个同样复杂的问题。
– Edsger Dijkstra, 1972年图灵奖获奖感言
●第一次软件危机 （60年代~70年代）
这个时期主要的软件开发方式是使用机器语言或者汇编语言在特定的机器上进行软件的设计与编写。此时的软件规模较小，也不需要使用系统化的软件开发方法，
基本上是个人设计编码、个人操作使用的模式。这个时代的程序一个典型特征就是依赖特定的机器，程序员必须根据所使用的计算机的硬件特性编写特定的程
序。
然而从60年代中期开始，大容量、高速度计算机问世，程序设计的复杂度也随之增长。1968 年北大西洋公约组织的计算机科学家在联邦德国召开国际会
议，第一次讨论软件危机问题，并正式提出“软件工程”一词，从此一门新兴的工程学科——软件工程学——为研究和克服软件危机应运而生，“软件危机”的概
念也是在那次会议上由F. L. Bauer提出的。
当时业界最迫切的需求是需要在不损失性能的前提下获得更好的“抽象性”和“可移植性”。此时，比汇编和机器语言更高级的语言相聚诞生，典型的代表莫过于
C语言（1972年）。C语言让程序员能让程序员编写的代码在没有或只有较少机器相关性的同时又有不输于汇编语言的性能，而且丰富的语言特性也使得编程
难度大大降低，成功的解决了“抽象性”和“可移植性”的问题。
●第二次软件危机（80年代~90年代）
这次危机可以归因于软件复杂性的进一步增长。这个时候的大规模软件常常由数百万行代码组成，有数以百计的程序员参与其中，怎样高效、可靠的构造和维护这
样规模的软件成为了一个新的难题。著名的《人月神话》中提及，IBM公司开发的OS/360系统共有4000多个模块，约100万条指令，投入5000
人年，耗资数亿美元，结果还是延期交付。在交付使用后的系统中仍发现大量（2000个以上）的错误。
这时候人们典型需求的是更好的“可组合性”(Composability)、“可延展性”(Malleability)以及“可维护
性”(Maintainability)。程序的性能已经不是一个大问题了，因为摩尔定律能帮你搞定它（70年代编写的C程序仍然能在现在的计算机上运
行，而且它还更快！）。为了解决这次危机，面向对象的编程语言（C++、C#、Java等）诞生了，更好的软件工程方法（设计模式、重构、测试、需求分
析等等）诞生了，而程序员们也越来越不需要知道硬件是怎么工作的了。软件和硬件的界限越来越牢固，Java编写的代码能在任何JVM支持的平台上运行，
程序员也非常乐于享受这样的便利。
●第三次软件危机（2005年至今）
兄弟们，“免费的午餐已经结束了”。
摩尔定律在串行机器上宣告失效，多核时代正式来临！
这个时候怎样在多核平台上仍然能保持性能的持续增长就成为了这一次软件危机的核心。并行编程给我们带来了许许多多新的技术难题，现阶段想要高效的利用这
些多核平台以获得更好的性能，就必须对计算机的硬件有较深入的理解，而广大程序员却更喜欢能有一些更加便利的编程模型（也许是一门新的语言、也许是新的
编程模型）来简单高效地进行并行编程。我们正处在这次危机的开端，前路满是荆棘。但是只要有问题，就会有机会。多核时代，你们的机会在哪里呢？
--
Guancheng Chen
Twitter @guancheng
Blog: http://www.parallellabs.com
Kula
--
To unsubscribe, reply using "remove me" as the subject.
qiaojie
Guancheng Chen
On 4月1日, 下午1时12分, qiaojie <qiao...@gmail.com> wrote:
> 一言以蔽之：没有银弹。
>
> 2010/4/1 Guancheng Chen <chenguanch...@gmail.com>
Guancheng Chen
On 4月1日, 下午1时11分, Kula <kulas...@gmail.com> wrote:
> 事实上 我比较期待在多核时代 fp能够脱颖而出. 出现一些表现力强.简洁的语言.
>
> 2010/4/1 Guancheng Chen <chenguanch...@gmail.com>
>
>
>
> > The major cause of the software crisis is that the machines have
> > become several orders of magnitude more powerful! To put it quite
> > bluntly: as long as there were no machines, programming was no problem
> > at all; when we had a few weak computers, programming became a mild
> > problem, and now we have gigantic computers, programming has become an
> > equally gigantic problem.
>
> > 造成软件危机的主要原因是因为计算机的计算能力正在呈指数级地增长！说的简单些：在没有计算机的时候，编程根本就不是一个问题；当一些计算能力较弱的计
> > 算机出现时，编程成了一个中等难度的问题，而现在，我们拥有了计算能力超绝的计算机，编程就变为了一个同样复杂的问题。
>
> > - Edsger Dijkstra, 1972年图灵奖获奖感言
>
> > ●第一次软件危机 （60年代~70年代）
>
> > 这个时期主要的软件开发方式是使用机器语言或者汇编语言在特定的机器上进行软件的设计与编写。此时的软件规模较小，也不需要使用系统化的软件开发方法，
> > 基本上是个人设计编码、个人操作使用的模式。这个时代的程序一个典型特征就是依赖特定的机器，程序员必须根据所使用的计算机的硬件特性编写特定的程
> > 序。
> > 然而从60年代中期开始，大容量、高速度计算机问世，程序设计的复杂度也随之增长。1968 年北大西洋公约组织的计算机科学家在联邦德国召开国际会
> > 议，第一次讨论软件危机问题，并正式提出"软件工程"一词，从此一门新兴的工程学科----软件工程学----为研究和克服软件危机应运而生，"软件危机"的概
Alleluia
Alleluia
该怎么写程序还怎么写程序,那些玩艺都不是普通程序员需要操心的事情.毕竟软件中90%代码都是跟人打交道的Non-Criticle的trivial
问题.
Guancheng Chen
lv yi
上面的链接是我前阵子写的一个基于GO,Websocket, html5 canvas 小程序h5-monitor的发布手记
2010/4/2 Guancheng Chen <chengu...@gmail.com>:
--
--
我想和你分享
-----------------------------------------------------------
url: http://lvscar.info
Gtalk: lvs...@gmail.com | MSN: lvs...@msn.com
lv yi
http://www.lvscar.info/blog/?p=108
上面的链接是一个基于GO,Websocket, html5 canvas的小程序h5-monitor的发布手记
woo
作为"thread",的开销跟fp语言差不多，至少语法比erlang好看（可能是我c看多了。。)
加上有channel的实现,感觉port fp语言到go上也不是很复杂的事情
Linker
Dbger
《程序员修炼之道》中在十年前就提出了”Always Design for Concurrency “，人家在危机之前（2005）就已经提出这点了
技术博客:http://debuggingnow.com
我的豆瓣:http://www.douban.com/people/baiyanhuang/
woo
另外我觉得也不算太杂吧，相对与c，加上了gc,goroutine,channel而已，比c++范式少多了...
请问您有什么高见
陨落雕
On Apr 5, 6:50 am, Dbger <baiyanhu...@gmail.com> wrote:
> 我还是比较担心，一些大型的计算密集型软件，如果不能很好的转型支持多核，会因为性能原因被淘汰 --- 如果你竞争对手支持了的话。
> 而庞大的串行代码量，令这种转型什么困难。
>
> 《程序员修炼之道》中在十年前就提出了"Always Design for Concurrency "，人家在危机之前（2005）就已经提出这点了
>
> 技术博客:http://debuggingnow.com
> 我的豆瓣:http://www.douban.com/people/baiyanhuang/
>
> 2010/4/5 Linker <linker.m....@gmail.com>
>
>
>
> > GO就算了吧。
> > 一个大杂烩。实现非常不成熟。
>
> > 2010/4/5 woo <woosi...@gmail.com>
>
> > 过来顶一下go，轻量级的goroutine的确用起来很方便
> >> 作为"thread",的开销跟fp语言差不多，至少语法比erlang好看（可能是我c看多了。。)
> >> 加上有channel的实现,感觉port fp语言到go上也不是很复杂的事情
>
> >> On 13:38 Mon 05 Apr , lv yi wrote:
> >> > 用GO写并发程序很爽，有C系语言背景的朋友，学习成本估计和python差不多
>
> >> >http://www.lvscar.info/blog/
>
> >> > 上面的链接是我前阵子写的一个基于GO,Websocket, html5 canvas 小程序h5-monitor的发布手记
>
> >> > 2010/4/2 Guancheng Chen <chenguanch...@gmail.com>:
Feng Yu
专注 高性能容错分布式服务器的研究和实现
http://blog.yufeng.info
Dbger
就是计算量很大，耗时较多的软件，比如CAD，气象模拟软件之类的，有些软件由于历史原因是单线程的，它并不会因为你加多个核而自动提升性能，要支持多线程是需要很大的代码重构的。
陨落雕
On Apr 5, 8:37 pm, Dbger <baiyanhu...@gmail.com> wrote:
> >>不清楚你说的计算密集型软件是什么？
>
> 就是计算量很大，耗时较多的软件，比如CAD，气象模拟软件之类的，有些软件由于历史原因是单线程的，它并不会因为你加多个核而自动提升性能，要支持多线程是需要很大的代码重构的。
>
> 技术博客:http://debuggingnow.com
> 我的豆瓣:http://www.douban.com/people/baiyanhuang/
>
> 2010/4/5 Feng Yu <mryuf...@gmail.com>
>
> > 我觉得GO实现的非常有理性,而且底层做的很不错的...
>
> > 专注 高性能容错分布式服务器的研究和实现
> >http://blog.yufeng.info
>
> > 2010/4/5 Linker <linker.m....@gmail.com>
>
> > GO就算了吧。
> >> 一个大杂烩。实现非常不成熟。
>
> >> 2010/4/5 woo <woosi...@gmail.com>
>
> >> 过来顶一下go，轻量级的goroutine的确用起来很方便
> >>> 作为"thread",的开销跟fp语言差不多，至少语法比erlang好看（可能是我c看多了。。)
> >>> 加上有channel的实现,感觉port fp语言到go上也不是很复杂的事情
>
> >>> On 13:38 Mon 05 Apr , lv yi wrote:
> >>> > 用GO写并发程序很爽，有C系语言背景的朋友，学习成本估计和python差不多
>
> >>> >http://www.lvscar.info/blog/
>
> >>> > 上面的链接是我前阵子写的一个基于GO,Websocket, html5 canvas 小程序h5-monitor的发布手记
>
> >>> > 2010/4/2 Guancheng Chen <chenguanch...@gmail.com>:
LeeoNix
Alleluia
Alan Kay的那句话怎么说来着"People who seriously cares about performance should
make their own hardware"。
一般来说,计算密集型的东西都是轮不到普通程序员来搞得,最简单的一个实例就是实时计算机图形学,最核心性能最关键的图形算法要么给封装在DX,OGL
的API里,要么就是显卡里面直接用硬件做掉了.你要对一张纹理进行缩放,根本不用自己去写双线性,B样条之类的插值算法,直接在API给函数一个参数
就完了.你自己写的东西还未必有他们做的快做的好.
On 4月6日, 上午9时51分, LeeoNix <leeoni...@gmail.com> wrote:
> 看到Edsger Dijkstra，膜拜，然后不做讨论。
>
Guancheng Chen
的吧。一个很实际的例子是GraphicsMagick（Flickr就在用它），他们用到了OpenMP来并行化一些loop：http://
www.graphicsmagick.org/OpenMP.html
--
Guancheng Chen
Twitter @guancheng
Blog: http://www.parallellabs.com
On Apr 6, 4:11 am, Alleluia <allul...@gmail.com> wrote:
> 计算密集型的问题,语言是极其次要极其次要的问题.算法>硬件>软件>语言.
> Alan Kay的那句话怎么说来着"People who seriously cares about performance should
> make their own hardware"。
> 一般来说,计算密集型的东西都是轮不到普通程序员来搞得,最简单的一个实例就是实时计算机图形学,最核心性能最关键的图形算法要么给封装在DX,OGL
> 的API里,要么就是显卡里面直接用硬件做掉了.你要对一张纹理进行缩放,根本不用自己去写双线性,B样条之类的插值算法,直接在API给函数一个参数
> 就完了.你自己写的东西还未必有他们做的快做的好.
>
> On 4月6日, 上午9时51分, LeeoNix <leeoni...@gmail.com> wrote:
>
> > 看到Edsger Dijkstra，膜拜，然后不做讨论。
>
> > 在 2010年4月1日 下午7:06，Guancheng Chen <chenguanch...@gmail.com>写道：
>
> > > The major cause of the software crisis is that the machines have
> > > become several orders of magnitude more powerful! To put it quite
> > > bluntly: as long as there were no machines, programming was no problem
> > > at all; when we had a few weak computers, programming became a mild
> > > problem, and now we have gigantic computers, programming has become an
> > > equally gigantic problem.
>
> > > 造成软件危机的主要原因是因为计算机的计算能力正在呈指数级地增长！说的简单些：在没有计算机的时候，编程根本就不是一个问题；当一些计算能力较弱的计
> > > 算机出现时，编程成了一个中等难度的问题，而现在，我们拥有了计算能力超绝的计算机，编程就变为了一个同样复杂的问题。
>
> > > - Edsger Dijkstra, 1972年图灵奖获奖感言
>
> > > ●第一次软件危机 （60年代~70年代）
>
> > > 这个时期主要的软件开发方式是使用机器语言或者汇编语言在特定的机器上进行软件的设计与编写。此时的软件规模较小，也不需要使用系统化的软件开发方法，
> > > 基本上是个人设计编码、个人操作使用的模式。这个时代的程序一个典型特征就是依赖特定的机器，程序员必须根据所使用的计算机的硬件特性编写特定的程
> > > 序。
> > > 然而从60年代中期开始，大容量、高速度计算机问世，程序设计的复杂度也随之增长。1968 年北大西洋公约组织的计算机科学家在联邦德国召开国际会
> > > 议，第一次讨论软件危机问题，并正式提出"软件工程"一词，从此一门新兴的工程学科----软件工程学----为研究和克服软件危机应运而生，"软件危机"的概
Guancheng Chen
当修改有时也是不可避免的。但是这些都是普通程序员以后很有可能会接触到的，因为它不是到让你发明一个高性能的并行算法，而是让你对串行算法做一些相对
较容易的修改以使它并行化。
songyy
感觉这个应该是正常的吧，毕竟在我们用计算器的时候也没发现过有什么问题。
不过文章的确给我指了一点方向：“软件的正确性（较少的逻辑错误）”在以后的实用中会越来越重要，重要性甚至大过一个很实用的想法的诞生——我想着也是
严重区别一个好坏程序员的关键：能否写出对的、少bug的程序。