主题：【原创】进程的反击 -- zllwy

那现在C/C++是不是算远古时代的东东了。

Java的问题部分归咎于Sun和JCP，部分归咎于Oracle，多少年了Java不思进取，Java 7的feature更是被Oracle砍了很多。在Java developer的圈子里面有一种Java完蛋了的气氛，大家纷纷讨论Java的后继是什么。Scala很有希望。不过我还是更喜欢Java一点，虽然Java的很多应该有的feature，比如closure，早该有了。

至于C/C++，应该分开讨论。C作为底层系统的语言我看还没有可以取代它的。C实际上是现代的汇编语言。应该没有人会用C来编写大型应用了。C++基本上被人诟病的很多，设计上很有问题。所以才会有很多新的语言试图修正这些问题。比如D号称是更好的C++。

甚至OOP的概念现在也在被重新审视。比如inheritance，很多人认为这是一个bad concept，有一篇很有名的blog说inheritance sucks。Go就没有inheritance，而是用interface，类似于duck typing，但是static的。这个就比inheritance要简单，灵活。

目前在programming language领域里面的创新和进步天天都在发生，如果作为程序员思维还停留满足在Java, C/C++，那很快就会落后的。:-)也许你要问我为什么要关心这些，Java, C/C++够用了。我想作为一个真正精益求精的程序员来说，永远追求更好的编程工具是一件很正常的事情。就像一个机械工程师，你的工具不趁手，你会不会去找更好用的呢。这毕竟影响到你的工作效率。对吧。

有空我来写写我目前的favorite language: Go。

几十万行应该算是大型吧。当然，也许是因为这些应用一般都有很长很长的历史（有些程序可以回溯到上世纪七八十年代）。现在看C还有很长的寿命，Fortran就算了。

现在很多情况下，写程序选用语言还是没法看自己的喜好，而是看自己想写什么样的东西。比如说想写一个跨平台的GUI，可以选的框架比较成熟的就是C/GTK+，C++/QT，Java/swing三样，还有他们的各种绑定。可以选择的语言有限。脚本语言方面，如果是想写Linux系统脚本，bash随手就可以用，什么也不用担心。跨平台的脚本一般考虑Python，最好的万能胶，之前有perl，现在不常用了。微软的批处理脚本就很杯具了，VBScript略好一些而已。当然据说现在到了win7好像有所改善。至于Go，D这样的语言现在只能当玩具玩，没办法库太少。就算lisp这样的老牌的语言，库还是不够丰富。现在的问题就是底层谁都没办法与C竞争（没办法人家操作系统一大半都是用C写的），高级一点的语言，没有个大型的函数库根本没法吸引大家编写应用。

说到继承的概念，很多人都做了讨论，像effective java中有就类似的条目。

我现在很是怀疑，每一种新的语言出现，是不是有它的必要性，还是往往变成了解决一个问题，又创造了新的其他问题？

我觉得很奇怪，为什么就不能在现有语言上改造呢？或者说，新的语言出现，有多少是语法的变动，有多少是因为功能的变动（或者说函数库诸如此类的）。

铁手回帖了。

回顾一下编程语言的历史，可以发现新的主要语言的出现都是随着编程的需要而兴起的某种新的模式而出现的。高级语言是为了可读，OOP是为了大规模应用的需要（比如代码重用）。现在则是functional language中的很多概念的流行。很多新的语言都试图把传统的语言和functional language中的精华结合起来，给程序员提供更强大的工具，减少编程的错误，提高可读性，提供很多程序中常用的pattern等等。也许你会怀疑到底这些新的功能起了多么重要的作用。至少从我的体会来说，Go的goroutine和CSP模式是我一直在寻找的语言功能。因为我的需要是写大规模并行的web service，用thread显然已经不能适应并发规模了，用event-driven又很难写，而且容易出错，goroutine和channel提供了非常简洁和方便的抽象。最终的结果就是我可以用很少的代码写出可靠而高效的web service。另外的例子就是很多人喜欢用closure或者generator，觉得可以写很精练的代码，所以很多新语言都提供这样的feature。Java 7也要支持closure了。所以，新的语言最终是由需求而产生的。当然，如果你没有这样的需要，也就没有必要追求新的语言了。

而另外一部分将变成硬件driver register manager和标准化远程进程间通信协议。

过去的操作系统包揽一切。cpu本身像是dummy。

现在的cpu本身，一方面是多重缓存，本身就有进行内存调度功能，另一方面多核，在16个或32个核之间的进程调度，已经需要和过去的操作系统一样复杂。

尤其广域网的分布计算，资源可能是在全分布的。一个数千个内核组成的超级计算机，和互联网几千个PC，之间没有本质不同，除了联接速度。但互联网几千台PC还是很难智能地形成超级计算模式。因为现在的操作系统还是面向单机资源的。

慢慢地cpu集成越来越多的核，还有GPU，缓存。这样cpu内部就形成了一个过去的电脑主机，过去的操作系统核心将进驻cpu内，由硬件完成或是可编程微代码完成。

intel收购了防病毒软件，新的intel已经在硬件中内置了高清视频的版权验证。那么不同计算机之间远程的进程安全验证也可以内置。那么将来防病毒软件的部分功能将内置在cpu中，尤其是多个电脑之家进行进程调用可以由cpu进行信任验证。每个cpu可以内置独一无二无法改变的识别码，像网卡MAC或IP6。进程是否含有病毒或非法操作也由cpu自己验证。这种进程调度可以直接由cpu完成控制，甚至由cpu进行远程的跨互联网的进程调度安全认证。那么跨互联网的电脑可以以进程调度为方式轻松形成超级计算。

现在的google等主导的html5软件沙箱是以牺牲代码执行效率为代价的。远不如cpu内建硬件沙箱，本地进程和远地进程由cpu自动分配不同的权限，由于是硬件内置的，任何病毒都无法更改。而且可以直接远程调用机器码执行，而不是任何script

这个变化很可能intel会主导。intel收购防病毒公司肯定不是指望卖软件的，而是打算cpu内部集成某种进程安全验证功能。

就好象如果某种病市场上有很多种药物在卖，那么不用问就知道，这些药没有一种是管用的。有疗效也不治愈。

我觉得语言很多就说明改变语言不解决问题，而是要改操作系统。

这个想法的岁数比这个版上至少一半的人都大

首先CPU没有storage，你这操作系统放哪儿?就算是你在CPU里加一块flash能存储“OS”，那这CPU卖给谁呢？你都把OS给做好了，苹果的OS，微软的OS，以及Linux和你这“OS”怎么个关系？

我们说的操作系统好像是一个政府，管理的是整个计算机资源。事情远远比job scheduling要多，内存，Disk IO, Network, File, Security等等。CPU没法管理它以外和它以上的东西。它面对的是汹涌而来的x86指令，他的任务是怎么把这些指令用最短的时候或最小的能耗处理完，所以它是系统的一部分，而不是系统。

CPU的工作调动是很复杂，即使在单核时代也不简单。那么深的pipeline，并且要out-of-order执行，还要进行预判，判断错了还要推倒重来，要pre-fetch可能会用到的数据，要智能的保存cache里的东西。。。它的很多调度原则和算法和OS可能一致，但是这并不意味着OS进驻住到CPU里面。

Intel每次更新CPU的结构的时候，它的compiler都会相应的更新，使得应用程序可以利用新的feature，同时Intel还会跟主要的OS厂商密切合作，使得OS能发挥出新的构架的特点。以前看微软VC++2005发布的时候，里面很多feature就是从Intel那里拿去的。

Intel会搞OS吗？当然会。事实上它已经在搞了（譬如说MeeGo）,但那是另外的部门，不是搞CPU的那帮人。

cpu是多核集成的，已经有了GPU。可以有一块FPGA专门负责前处理。所以要有专门的进程间通信协议。所有机器的进程都变成标准格式。如果不是X86代码的进程，就要进行翻译，当然执行就慢了。

当然不管长期短期，我觉得intel是有资源可以做这个事情的。

intel还投资了FPGA公司，有防病毒公司。这些凑在一起，本身就是个片上电脑。

以前没有线程的时候，那没什好说的，都得靠进程了。但这是笨办法，问题很多。所以当线程出现的时候，是计算机史的一个飞跃。

线程小名叫做轻量级进程（light-weight process），能干和进程类似的活但开销却小很多，所以当然是很多问题的最佳人选。但是它的scalability是个问题，线程管理不好的话，thread swap in and out的时间可能比干正经活的时间还要大。比如早期的Java，4个以上的CPU就很难利用好。

解决问题的途径有两条：

1）提高线程的scalability，比如Java在1.5以后引入了一真个的concurrent package，另外VM也改进了很多，最大可能的减少thread间的contention，提高多CPU或是多核下的性能。

2）把大的问题break down，多来几个进程，每个进程内的thread在一个合理可控制的范围内，避免thread间的contention。这样就全局来看系统的利用率可能是最优的。

所以现在最流行的不是什么“进程反击”，而是线程+进程的一个hybrid局面。就Google的chrome而言也是这样的，chrome的UI process有20多个thread，就是每个render process也有4个thread。所以进程和线程不是谁取代谁，谁吃掉谁的问题，而是怎么联合作战，共同完成任务的情形。

还有，现在大一点的系统大多是NUMA Architecture（Non-Uniform Memory Access），任务分解到多个进程上，每个进程分配在某个或某些个CPU上，接触某个bank或某几个靠得最近的内存，这可能是一种最合理的运行方式了。

俺都怀疑俺是不是好长时间没更新知识了

虚拟化越来越重要。我觉得将来把VMM做在firmware里面是很有可能的。VMM本身也不大。这样买来的机器就能直接运行多个VM，而且将来的操作系统都可以直接支持在VMM里面高效运行。

不过以Linux为例，我觉得不完全是这样。在Linux kernel中，process和thread的唯一区别是是否共享地址空间，它们甚至都是用fork()系统调用创建的，只是参数不同。所以process不是必须的用于并行计算的单元。thread就足够了。process更多是起到隔离的作用，使得app之间的干扰减少，系统更加可靠。以前thread对于利用多个cpu core有问题，那是Linux kernel实现的问题。现在已经没有问题了。如果你的程序想充分利用各个cpu core，创建多于core数量的threads就可以了。