主题：【原创】进程的反击 -- zllwy
家园 很好的想法 虚拟化越来越重要。我觉得将来把VMM做在firmware里面是很有可能的。VMM本身也不大。这样买来的机器就能直接运行多个VM，而且将来的操作系统都可以直接支持在VMM里面高效运行。
家园 我认为短期内不可能 首先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的那帮人。
家园 我觉得看你怎么理解什么是OS了 OS是啥，OS是一个抽象层而已，能把硬件抽象出来，提供一套API，让外围能有效地使用硬件。 所以，OS的核心代码其实很小很少。现在的OS之所以这么大，是因为附送了一大堆添头。 不过对于最终用户来说，他们在意是那堆添头好不好用 ：）
家园 就算是硬件插象层也不合适 CPU怎么管理文件，怎么管理外设，怎么LOAD设备驱动，怎么管理用户。。。CPU压根就不知道也不在乎这些东西。
CPU还是一个硬件设备，和OS不一会事儿。如果你非说OS要进驻CPU，那我还说OS要进驻GPU呢？不行吗。
家园 cpu是多核集成的，可以有专门FPGA核负责调度，硬OS cpu是多核集成的，已经有了GPU。可以有一块FPGA专门负责前处理。所以要有专门的进程间通信协议。所有机器的进程都变成标准格式。如果不是X86代码的进程，就要进行翻译，当然执行就慢了。
当然不管长期短期，我觉得intel是有资源可以做这个事情的。
intel还投资了FPGA公司，有防病毒公司。这些凑在一起，本身就是个片上电脑。
家园 操作系统进驻CPU 这个想法的岁数比这个版上至少一半的人都大
家园 或许与cpu的性能提高方式转变有关 这个是不是与cpu的性能提高方式转变有关,过去cpu的主要通过提高主频的方式提高性能,这种方式,因为线程的开销小,而进程提供的并行优势无法发挥.
现在方法是提高cpu core的数目,进程的并行优势就很明显了,加上你提出的其他的好处.
至少在非移动处理的领域是这样的.
不过对于移动处理,或许会有些不同.
家园 倒也不全是那样 以前没有线程的时候，那没什好说的，都得靠进程了。但这是笨办法，问题很多。所以当线程出现的时候，是计算机史的一个飞跃。
线程小名叫做轻量级进程（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或某几个靠得最近的内存，这可能是一种最合理的运行方式了。
家园 你说的这个是桌面 在server端，早就是这样了，比如fast cgi，
再比如python，python由于自己实现的原因，有个GIL，意思就是说每个python的解释器进程，都有一个全局锁，每个线程在运行之前，都要得到这把锁。这就使得python下面多线程编程没有办法用到多cpu的好处，始终只能用到一个core。
GIL是大家的肉中刺，眼中钉，一票子人想着把这个东西拿掉。不过弄了半天，推出的是一个另类解决方案，就是提供了multiprocessing这个库，直接用process来模拟thread，诸如pool阿，lock之类的东西都一并打包奉送。
- 复 你说的这个是桌面
家园 server端的并发 cgi，那是多么古老的技术啊。所以我说进程又回来了，而不是出现啊。而且cgi是个协议，跟进程没有必然联系。
说到server端的并发技术，也是很有意思的一个问题。早期的web server是用process，比如apache（当然现在也通过模块支持线程了）。然后threading成为主流。但thread对于server的大量并发请求还是不够细，操作系统只能支持有限的threads，著名的c10k问题就是关于这个的。很多模型出现了，比如SEDA，event-driven。目前event-driven是最流行的，因为event-driven不需要维护thread的context（register, stack等等），少量的thread就可以对付大量的并发请求。很多AIO（异步I/O）的程序库应运而生，比如Java NIO，Netty，libevent(C)。现在特别热火的Node.js（用javascript写的web server）也是event-driven。不过，event-driven在编程上比较难写而且容易出错，是我很讨厌的一种模式。我比较看好Actor/message passing或者CSP之类的并发编程技术，erlang是最早在这方面探索的。基本想法就是并发的粒度进一步减少，这样就不受thread limit的限制。这就是所谓的coroutine。coroutine依靠合作的方式进行切换，需要比较小的stack。coroutine之间的同步可以采用message passing。message passing和share memory是等效的，但相对于thread的传统同步方式，message passing比较容易写，而且不容易出错。目前有很多新的编程语言在探索这种方式，或者改进现有的语言来支持。比如scala，kilim，和我目前最喜欢的语言Go。Go的goroutine就是类似于coroutine的实现，多个goroutine被map到有限的几个线程上去（基本上就等于你机器有的cpu core的数量就可以了）。goroutine之间用channel来传递消息。一个程序可以生成大量的goroutine，这样我们就又可以回到同步，顺序的方式来写server了。所以用Go来写networking的程序是最容易的。所以在server端，基本趋势就是并发的粒度越来越小。我还没有看到有回到process的必要。
至于GIL是python设计的一大缺陷，但这不以为着python是基于进程的，python也是有thread的，只是有GIL这个bottleneck，限制了并发的程度。另外，python 3这个问题好像已经解决了。
家园 语言品种太多了，搞的人眼花缭乱 我现在很是怀疑，每一种新的语言出现，是不是有它的必要性，还是往往变成了解决一个问题，又创造了新的其他问题？
我觉得很奇怪，为什么就不能在现有语言上改造呢？或者说，新的语言出现，有多少是语法的变动，有多少是因为功能的变动（或者说函数库诸如此类的）。