西西河

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

共:💬48 🌺136
分页树展主题 · 全看首页 上页
/ 4
下页 末页
      • 家园 很好的想法

        虚拟化越来越重要。我觉得将来把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或某几个靠得最近的内存,这可能是一种最合理的运行方式了。

        • 家园 说得不错

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

    • 家园 你说的这个是桌面

      在server端,早就是这样了,比如fast cgi,

      再比如python,python由于自己实现的原因,有个GIL,意思就是说每个python的解释器进程,都有一个全局锁,每个线程在运行之前,都要得到这把锁。这就使得python下面多线程编程没有办法用到多cpu的好处,始终只能用到一个core。

      GIL是大家的肉中刺,眼中钉,一票子人想着把这个东西拿掉。不过弄了半天,推出的是一个另类解决方案,就是提供了multiprocessing这个库,直接用process来模拟thread,诸如pool阿,lock之类的东西都一并打包奉送。

      关键词(Tags): #process#python
      • 家园 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这个问题好像已经解决了。

        • 家园 语言品种太多了,搞的人眼花缭乱

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

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

分页树展主题 · 全看首页 上页
/ 4
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河