x****u
发帖数: 44466 | 1 http://www.yinwang.org/blog-cn/2013/04/14/os-design/
一种新的操作系统设计
我一直在试图利用程序语言的设计原理，设计一种超越“Unix 哲学”的操作系统。这
里是我的设想：
这种系统里面的程序间通信不使用无结构的字符串，而是使用带有类型和结构的数据。
在这样的系统里面，“程序”的概念基本上完全消失。系统由一个个的“函数”组成，
每个函数都可以调用另外一个函数，通过参数传递数据。每个函数都可以并发执行。
由于参数是一个数据结构，而不是字符串，这避免了程序间通信繁琐的“编码”和“解
码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理
特定类型的数据，这使得像 “OLE 嵌入”这样的机制变得极其简单。
所有函数由同一种先进的高级程序语言写成，所以函数间的调用完全不需要“翻译”。
由于这种语言不允许应用程序使用“指针运算”，应用程序不可能产生 segfault 一类
愚蠢的错误。
由于没有指针运算，系统不再需要现代处理器提供的“内存映射”机制，以及 TLB。这
使得内存访问效率大幅提高。而且简化了处理器的设计。
操作系统使用与应用程序相同的高级语言写成（可能需要支持一些“特权操作”），至
于“系统调用”，只不过是调用另外一个函数。
操作系统的“shell”，不过是一个这种高级语言的 REPL。用户可以在终端输入各种函
数调用，从而启动进程的运行。
系统不需要 SQL，不需要关系式数据库。所有的数据都作为“对象”，保存在一个分布
式的数据空间。
系统不需要“文件系统”。所有的数据，包括“进程上下文”自动被“版本控制”，在
合适的时候作为对象同步到磁盘。所以即使在机器掉电的情况，绝大部分的数据和进程
能够在电源恢复后自动继续运行。
程序员和用户完全不需要知道“数据库”或者“文件系统”的存在。程序假设自己拥有
无穷大的空间，可以任意的构造数据。
为了减少数据的移动，系统根据数据的位置，选择： 1）迁移数据，或者 2）迁移处理
数据的“进程”。程序员不需要使用 MapReduce，Hadoop 等，就能进行大规模并行计
算。 这个操作系统是如此的“一致”，以至于所有的用户和程序员，只需要学会一种
很简单的程序语言。
我曾经以为我是第一个想到这个做法的人。可惜的是，调查之后发现，很多人早就已经
做出了类似的系统（虽然缺少对把它用于分布式计算的设想）。Lisp Machine 似乎是
其中最接近的一个。Oberon 是另外一个。我只能说，英雄所见略同。 |
d****i
发帖数: 4809 | 2 haha, 共产主义？
【在 x****u 的大作中提到】
: http://www.yinwang.org/blog-cn/2013/04/14/os-design/
: 一种新的操作系统设计
: 我一直在试图利用程序语言的设计原理，设计一种超越“Unix 哲学”的操作系统。这
: 里是我的设想：
: 这种系统里面的程序间通信不使用无结构的字符串，而是使用带有类型和结构的数据。
: 在这样的系统里面，“程序”的概念基本上完全消失。系统由一个个的“函数”组成，
: 每个函数都可以调用另外一个函数，通过参数传递数据。每个函数都可以并发执行。
: 由于参数是一个数据结构，而不是字符串，这避免了程序间通信繁琐的“编码”和“解
: 码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理
: 特定类型的数据，这使得像 “OLE 嵌入”这样的机制变得极其简单。
|
x****u
发帖数: 44466 | 3 第一想法是逃了那么多课也能本科毕业，接着就想起了幼儿园时画过的新型宇宙飞船图
纸。
【在 d****i 的大作中提到】
: haha, 共产主义？
|
d****i
发帖数: 4809 | 4 或者是空想社会主义？
【在 d****i 的大作中提到】
: haha, 共产主义？
|
x****u
发帖数: 44466 | 5 这可是CS本科啊，上课学的东西都喂狗了么。
【在 d****i 的大作中提到】
: 或者是空想社会主义？
|
n******t
发帖数: 4406 | 6 问题是Unix系统里面通信谁说不带结构的？不知道这丫在说什么。
【在 x****u 的大作中提到】
: http://www.yinwang.org/blog-cn/2013/04/14/os-design/
: 一种新的操作系统设计
: 我一直在试图利用程序语言的设计原理，设计一种超越“Unix 哲学”的操作系统。这
: 里是我的设想：
: 这种系统里面的程序间通信不使用无结构的字符串，而是使用带有类型和结构的数据。
: 在这样的系统里面，“程序”的概念基本上完全消失。系统由一个个的“函数”组成，
: 每个函数都可以调用另外一个函数，通过参数传递数据。每个函数都可以并发执行。
: 由于参数是一个数据结构，而不是字符串，这避免了程序间通信繁琐的“编码”和“解
: 码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理
: 特定类型的数据，这使得像 “OLE 嵌入”这样的机制变得极其简单。
|
x****u
发帖数: 44466 | 7 他说的是所有IPC或者内核信号传递都使用reflection吧。刚有人说程序语言是CS的皇
冠，外行搞不了，这厮就来自我牺牲打脸。
【在 n******t 的大作中提到】
: 问题是Unix系统里面通信谁说不带结构的？不知道这丫在说什么。
|
d*******r
发帖数: 3299 | 8 他说的是，Unix用得最多的通信方式还是 stream 吧。
举例是，shell+cmd 的程序就是折腾一堆字符串，IPC 和 TCP 也是byte stream.
【在 n******t 的大作中提到】
: 问题是Unix系统里面通信谁说不带结构的？不知道这丫在说什么。
|
x****u
发帖数: 44466 | 9 shell怎么做和OS有什么关系，这家伙说的是系统级通信协议。
他都听说过lispMachine，也不查查这玩意为什么没成气候。
【在 d*******r 的大作中提到】
: 他说的是，Unix用得最多的通信方式还是 stream 吧。
: 举例是，shell+cmd 的程序就是折腾一堆字符串，IPC 和 TCP 也是byte stream.
|
b*****e
发帖数: 474 | 10 恩，这和造 Tower of Babel 的意义差不多吧
一直有人在做统一语言的事，也一直有人在不停地发明新语言，哈哈
【在 x****u 的大作中提到】
: http://www.yinwang.org/blog-cn/2013/04/14/os-design/
: 一种新的操作系统设计
: 我一直在试图利用程序语言的设计原理，设计一种超越“Unix 哲学”的操作系统。这
: 里是我的设想：
: 这种系统里面的程序间通信不使用无结构的字符串，而是使用带有类型和结构的数据。
: 在这样的系统里面，“程序”的概念基本上完全消失。系统由一个个的“函数”组成，
: 每个函数都可以调用另外一个函数，通过参数传递数据。每个函数都可以并发执行。
: 由于参数是一个数据结构，而不是字符串，这避免了程序间通信繁琐的“编码”和“解
: 码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理
: 特定类型的数据，这使得像 “OLE 嵌入”这样的机制变得极其简单。
|
|
|
d*******r
发帖数: 3299 | 11 他说的是主要是通信协议，比如IPC, TCP什么的stream抽象，但是也说了很多human
factor之类的东西，比如Unix默认的shell+cmd的控制方式。
我也好奇，Lips Machine 没流行主要是为什么呢？效率上不去？还是programmer们不
喜欢Lisp太多的括号? 或者政治原因？ 谁知道的，求指点 :)
【在 x****u 的大作中提到】
: shell怎么做和OS有什么关系，这家伙说的是系统级通信协议。
: 他都听说过lispMachine，也不查查这玩意为什么没成气候。
|
x****u
发帖数: 44466 | 12 很多所谓的新语言都是纯自娱自乐的。自视太高为了荒废学业，就是农民造潜艇了。
【在 b*****e 的大作中提到】
: 恩，这和造 Tower of Babel 的意义差不多吧
: 一直有人在做统一语言的事，也一直有人在不停地发明新语言，哈哈
|
x****u
发帖数: 44466 | 13 人类现在的电子技术，Lisp Machine在软件层实现是最有效率的。不少没好好上课的小
孩，总是以为任何东西放在底层都会更快，事实不是这样的啊。
【在 d*******r 的大作中提到】
: 他说的是主要是通信协议，比如IPC, TCP什么的stream抽象，但是也说了很多human
: factor之类的东西，比如Unix默认的shell+cmd的控制方式。
: 我也好奇，Lips Machine 没流行主要是为什么呢？效率上不去？还是programmer们不
: 喜欢Lisp太多的括号? 或者政治原因？ 谁知道的，求指点 :)
|
p***o
发帖数: 1252 | 14 通信协议的表示层不就是干这个的么?
【在 d*******r 的大作中提到】
: 他说的是主要是通信协议，比如IPC, TCP什么的stream抽象，但是也说了很多human
: factor之类的东西，比如Unix默认的shell+cmd的控制方式。
: 我也好奇，Lips Machine 没流行主要是为什么呢？效率上不去？还是programmer们不
: 喜欢Lisp太多的括号? 或者政治原因？ 谁知道的，求指点 :)
|
d*******r
发帖数: 3299 | 15 是干这个的，但是在Unix上，不是默认放在语言里的东西。所以用起来不够方便.
【在 p***o 的大作中提到】
: 通信协议的表示层不就是干这个的么?
|
d*******r
发帖数: 3299 | 16 能展开说说吗，我也是底层系统，处理器结构学的不好的小孩啊，呵呵
【在 x****u 的大作中提到】
: 人类现在的电子技术，Lisp Machine在软件层实现是最有效率的。不少没好好上课的小
: 孩，总是以为任何东西放在底层都会更快，事实不是这样的啊。
|
p***o
发帖数: 1252 | 17 Unix上都是库，比如XDR之类的。
【在 d*******r 的大作中提到】
: 是干这个的，但是在Unix上，不是默认放在语言里的东西。所以用起来不够方便.
|
g*****g
发帖数: 34805 | 18 看来王垠和你们对云计算都不了解，王垠想象中的系统，其实就是PaaS。GAE
的实现就很接近。直接存储对象，无限容量扩展。直接跑Java或者Python。 |
p***o
发帖数: 1252 | 19 他说的哪有那么高级，顶多一个jvm就差不多了。
【在 g*****g 的大作中提到】
: 看来王垠和你们对云计算都不了解，王垠想象中的系统，其实就是PaaS。GAE
: 的实现就很接近。直接存储对象，无限容量扩展。直接跑Java或者Python。
|
d*******r
发帖数: 3299 | 20 我看过王垠相关的几篇blog，我觉得王垠想象那个是更接近PaaS, 如果对比JVM的话,
只是他自己不是做系统的，对distributed system的设计不一定非常了解。而且他的意
思是，Python, Java 都不用，用一直他自己设计的语言，跑在一个他想象那种系统上
。不过这个总觉得是个大工程, 要做出来不容易.
【在 p***o 的大作中提到】
: 他说的哪有那么高级，顶多一个jvm就差不多了。
|
|
|
n******t
发帖数: 4406 | 21 最后TMD都是byte stream,这丫成天打手枪有意思吗？
【在 d*******r 的大作中提到】
: 他说的是，Unix用得最多的通信方式还是 stream 吧。
: 举例是，shell+cmd 的程序就是折腾一堆字符串，IPC 和 TCP 也是byte stream.
|
c***d
发帖数: 996 | 22 这个不就是基于json的javascript+webservice么， 并发，通信机制， namespace都是
现成的，要没有cross domain的限制广义的大规模数据共享和并行也不成问题。
chrome apps深得我心啊。
【在 x****u 的大作中提到】
: http://www.yinwang.org/blog-cn/2013/04/14/os-design/
: 一种新的操作系统设计
: 我一直在试图利用程序语言的设计原理，设计一种超越“Unix 哲学”的操作系统。这
: 里是我的设想：
: 这种系统里面的程序间通信不使用无结构的字符串，而是使用带有类型和结构的数据。
: 在这样的系统里面，“程序”的概念基本上完全消失。系统由一个个的“函数”组成，
: 每个函数都可以调用另外一个函数，通过参数传递数据。每个函数都可以并发执行。
: 由于参数是一个数据结构，而不是字符串，这避免了程序间通信繁琐的“编码”和“解
: 码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理
: 特定类型的数据，这使得像 “OLE 嵌入”这样的机制变得极其简单。
|
x****u
发帖数: 44466 | 23 CPU的指令集设计和性能有极大关系，支持复杂指令会导致速度和主频指数级下降。
【在 d*******r 的大作中提到】
: 能展开说说吗，我也是底层系统，处理器结构学的不好的小孩啊，呵呵
|
x****u
发帖数: 44466 | 24 我猜王垠根本看不起PaaS这个在他眼里“低级”的东西吧。
【在 d*******r 的大作中提到】
: 我看过王垠相关的几篇blog，我觉得王垠想象那个是更接近PaaS, 如果对比JVM的话,
: 只是他自己不是做系统的，对distributed system的设计不一定非常了解。而且他的意
: 思是，Python, Java 都不用，用一直他自己设计的语言，跑在一个他想象那种系统上
: 。不过这个总觉得是个大工程, 要做出来不容易.
|
x****u
发帖数: 44466 | 25 Windows上面对性能不敏感的IPC，官方是用COM做，如果能容忍更低的速度，就是
Automation，如果还嫌不够慢，可以上.net，王垠要的东西基本上就全了。
【在 d*******r 的大作中提到】
: 是干这个的，但是在Unix上，不是默认放在语言里的东西。所以用起来不够方便.
|
k**********g
发帖数: 989 | 26 I think he is thinking about Singularity OS of Microsoft Research. In
particular, Software Isolated Processes (SIPs).
http://research.microsoft.com/en-us/projects/singularity/
Quoted:
" ... For example, Singularity uses type-safe
languages and an abstract instruction set to enable
what we call Software Isolated Processes (SIPs).
SIPs provide the strong isolation guarantees of OS
processes (isolated object space, separate GCs,
separate runtimes) without the overhead of hardware-
enforced protection domains. In the current
Singularity prototype SIPs are extremely cheap;
they run in ring 0 in the kernel’s address space."
【在 x****u 的大作中提到】
: http://www.yinwang.org/blog-cn/2013/04/14/os-design/
: 一种新的操作系统设计
: 我一直在试图利用程序语言的设计原理，设计一种超越“Unix 哲学”的操作系统。这
: 里是我的设想：
: 这种系统里面的程序间通信不使用无结构的字符串，而是使用带有类型和结构的数据。
: 在这样的系统里面，“程序”的概念基本上完全消失。系统由一个个的“函数”组成，
: 每个函数都可以调用另外一个函数，通过参数传递数据。每个函数都可以并发执行。
: 由于参数是一个数据结构，而不是字符串，这避免了程序间通信繁琐的“编码”和“解
: 码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理
: 特定类型的数据，这使得像 “OLE 嵌入”这样的机制变得极其简单。
|
x****u
发帖数: 44466 | 27 完全两回事
Singularity is an experimental operating system built by Microsoft Research
between 2003 and 2010.[1] It was designed as a highly-dependable OS in which
the kernel, device drivers, and applications are all written in managed
code.
Contents [hide]
1 Workings
2 Security design
3 Project status
4 Similar projects
5 See also
6 References
7 External links
Workings[edit source | editbeta]
The lowest-level x86 interrupt dispatch code is written in assembly language
and C. Once this code has done its job, it invokes the kernel, whose
runtime and garbage collector are written in Sing# (an extended version of
Spec#, itself an extension of C#) and runs in unprotected mode. The hardware
abstraction layer is written in C++ and runs in protected mode. There is
also some C code to handle debugging. The computer's BIOS is invoked during
the 16-bit real mode bootstrap stage; once in 32-bit mode, Singularity never
invokes the BIOS again, but invokes device drivers written in Sing#. During
installation, Common Intermediate Language (CIL) opcodes are compiled into
x86 opcodes using the Bartok compiler.
【在 k**********g 的大作中提到】
: I think he is thinking about Singularity OS of Microsoft Research. In
: particular, Software Isolated Processes (SIPs).
: http://research.microsoft.com/en-us/projects/singularity/
: Quoted:
: " ... For example, Singularity uses type-safe
: languages and an abstract instruction set to enable
: what we call Software Isolated Processes (SIPs).
: SIPs provide the strong isolation guarantees of OS
: processes (isolated object space, separate GCs,
: separate runtimes) without the overhead of hardware-
|
d*******r
发帖数: 3299 | 28 哈哈，也不能完全这么说吧，那所有编程整到最后都是1010101... 但是直接用起来也
不方便嘛。
structured and reliable message 或者 function call 这类抽象，就比用 ordered
and reliable byte stream 舒服多了.
在Transport protocol 层，就有跟 TCP 平行的solutions，比如 SCTP (Stream
Control Transmission Protocol) 和一些 RPC. 只是这些东西没流行起来而已 (不管
什么原因).
而且 TCP/SCTP/RPC 都是可能 build 在 IP layer 上的，也就是在 distributed
system 中，byte stream 还是build在基本的 data/control massages 上的抽象，没
有 byte stream 也是可以的.
byte stream 很灵活很强大，但是人用起来，不一定最方便。
【在 n******t 的大作中提到】
: 最后TMD都是byte stream,这丫成天打手枪有意思吗？
|
d*******r
发帖数: 3299 | 29 设计指令集我一直没搞懂过，好像 Coursera 上有相关课，我回头搞明白了才敢跟别人
讨论
【在 x****u 的大作中提到】
: CPU的指令集设计和性能有极大关系，支持复杂指令会导致速度和主频指数级下降。
|
x****u
发帖数: 44466 | 30 现在的东西这么做，是因为只能这么做，不然就要付巨大的代价。
让某些退学SB感到方便是第100优先级的问题。
ordered
【在 d*******r 的大作中提到】
: 哈哈，也不能完全这么说吧，那所有编程整到最后都是1010101... 但是直接用起来也
: 不方便嘛。
: structured and reliable message 或者 function call 这类抽象，就比用 ordered
: and reliable byte stream 舒服多了.
: 在Transport protocol 层，就有跟 TCP 平行的solutions，比如 SCTP (Stream
: Control Transmission Protocol) 和一些 RPC. 只是这些东西没流行起来而已 (不管
: 什么原因).
: 而且 TCP/SCTP/RPC 都是可能 build 在 IP layer 上的，也就是在 distributed
: system 中，byte stream 还是build在基本的 data/control massages 上的抽象，没
: 有 byte stream 也是可以的.
|
|
|
x****u
发帖数: 44466 | 31 不是说光指令集本身的问题，和整个CPU原理，电子技术都有关联。
复杂的东西是可以直接做在硬件里，但搞不好会比软件模拟慢几个数量级。
【在 d*******r 的大作中提到】
: 设计指令集我一直没搞懂过，好像 Coursera 上有相关课，我回头搞明白了才敢跟别人
: 讨论
|
d*******r
发帖数: 3299 | 32 感觉这些观点还是有点一刀切啊
【在 x****u 的大作中提到】
: 现在的东西这么做，是因为只能这么做，不然就要付巨大的代价。
: 让某些退学SB感到方便是第100优先级的问题。
:
: ordered
|
g*****g
发帖数: 34805 | 33 灵活度问题，刷一个JVM在硬件里没问题。但出个bug升级就麻烦。
【在 x****u 的大作中提到】
: 不是说光指令集本身的问题，和整个CPU原理，电子技术都有关联。
: 复杂的东西是可以直接做在硬件里，但搞不好会比软件模拟慢几个数量级。
|
d*******r
发帖数: 3299 | 34 那以后会不会存在一种应用场景，真需要把某一个稳定版本的JVM刷到硬件里？比如某
些很需要performance的地方.
【在 g*****g 的大作中提到】
: 灵活度问题，刷一个JVM在硬件里没问题。但出个bug升级就麻烦。
|
t****t
发帖数: 6806 | 35 做成硬件过程中又会有bug的.
【在 d*******r 的大作中提到】
: 那以后会不会存在一种应用场景，真需要把某一个稳定版本的JVM刷到硬件里？比如某
: 些很需要performance的地方.
|
x****u
发帖数: 44466 | 36 所以说要看书啊，他的想法有半点靠谱，早发图灵奖了。实际上这么想的人几十年前就
撞得头破血流。
【在 d*******r 的大作中提到】
: 感觉这些观点还是有点一刀切啊
|
x****u
发帖数: 44466 | 37 刷进去的还是软件，如果JVM放在指令集部分，那么主频损失就大了。当年Linus不是受
雇于一个忽悠公司要做这个么。
【在 g*****g 的大作中提到】
: 灵活度问题，刷一个JVM在硬件里没问题。但出个bug升级就麻烦。
|
x****u
发帖数: 44466 | 38 小孩就是不明白，硬件之所以跑得快，是因为做的事情简单，总以为硬件天生速度快，
可惜做的事情太简单了。
【在 d*******r 的大作中提到】
: 那以后会不会存在一种应用场景，真需要把某一个稳定版本的JVM刷到硬件里？比如某
: 些很需要performance的地方.
|
d*******r
发帖数: 3299 | 39 我们小孩不懂就问~~ hehe
王吹捧的他老师写的Chez Scheme编译器到底能用不，据说Cisco也有项目在用。大牛们
来讲讲这东西的优劣呢。
听他的意思是有了这个，不需要有C那一层了，直接从Chez Scheme编译成目标代码就非
常快.
http://www.yinwang.org/blog-cn/2013/03/28/chez-scheme/
【在 x****u 的大作中提到】
: 小孩就是不明白，硬件之所以跑得快，是因为做的事情简单，总以为硬件天生速度快，
: 可惜做的事情太简单了。
|
y*******g
发帖数: 6599 | 40 lisp难道不是比c出现的早么。。
【在 d*******r 的大作中提到】
: 我们小孩不懂就问~~ hehe
: 王吹捧的他老师写的Chez Scheme编译器到底能用不，据说Cisco也有项目在用。大牛们
: 来讲讲这东西的优劣呢。
: 听他的意思是有了这个，不需要有C那一层了，直接从Chez Scheme编译成目标代码就非
: 常快.
: http://www.yinwang.org/blog-cn/2013/03/28/chez-scheme/
|
|
|
x****u
发帖数: 44466 | 41 1. 前缀表示法和中缀在性能上是等价的
2. 现在任何商业编译器都消除尾递归
【在 d*******r 的大作中提到】
: 我们小孩不懂就问~~ hehe
: 王吹捧的他老师写的Chez Scheme编译器到底能用不，据说Cisco也有项目在用。大牛们
: 来讲讲这东西的优劣呢。
: 听他的意思是有了这个，不需要有C那一层了，直接从Chez Scheme编译成目标代码就非
: 常快.
: http://www.yinwang.org/blog-cn/2013/03/28/chez-scheme/
|
d*******r
发帖数: 3299 | 42 那要搞个他想象的那种新的 "Lisp Machine" 风格的OS, 直接把C那一层都去掉，鼓励
只用一种高级语言 (e.g. Scheme). 现实不?
【在 x****u 的大作中提到】
: 1. 前缀表示法和中缀在性能上是等价的
: 2. 现在任何商业编译器都消除尾递归
|
x****u
发帖数: 44466 | 43 1. 可行
2. 速度降低几个数量级
【在 d*******r 的大作中提到】
: 那要搞个他想象的那种新的 "Lisp Machine" 风格的OS, 直接把C那一层都去掉，鼓励
: 只用一种高级语言 (e.g. Scheme). 现实不?
|
d*******r
发帖数: 3299 | 44 王写的文章里面有他自己的分析, 关于老 Lisp machine 为啥被 *nix 打败.
http://www.yinwang.org/blog-cn/2013/03/26/lisp-dead-alive/
【在 y*******g 的大作中提到】
: lisp难道不是比c出现的早么。。
|
x****u
发帖数: 44466 | 45 这篇文章槽点太多以至于完全无法吐槽。
【在 d*******r 的大作中提到】
: 王写的文章里面有他自己的分析, 关于老 Lisp machine 为啥被 *nix 打败.
: http://www.yinwang.org/blog-cn/2013/03/26/lisp-dead-alive/
|
d*******r
发帖数: 3299 | 46 王的文章里不是号称Chez Scheme无比快么。有用过的大牛来说说？
【在 x****u 的大作中提到】
: 1. 可行
: 2. 速度降低几个数量级
|
x****u
发帖数: 44466 | 47 两回事
【在 d*******r 的大作中提到】
: 王的文章里不是号称Chez Scheme无比快么。有用过的大牛来说说？
|
d*******r
发帖数: 3299 | 48 您老可以捡主要槽点说说，就当帮我们菜鸟补补课，呵呵. 我真的是纯讨教学习.
【在 x****u 的大作中提到】
: 这篇文章槽点太多以至于完全无法吐槽。
|
x****u
发帖数: 44466 | 49 说他这种话的人，不知道OS是干嘛的，也不知道CPU是干嘛的，也不知道数字电路是干
嘛的。
不是说把高级语言特性往下放速度就会倍增的，这是基本常识，大多数情况下速度都要
慢一个数量级。
【在 d*******r 的大作中提到】
: 您老可以捡主要槽点说说，就当帮我们菜鸟补补课，呵呵. 我真的是纯讨教学习.
|
d*******r
发帖数: 3299 | 50 高级特性往下放速度肯定不会增加了，主要是慢多少吧，有人用过那个Chez Scheme么?
我看王的这几篇blog，意思也是说，以前编译器写得不好，效能太差了，所以老Lisp不
好用
http://www.yinwang.org/blog-cn/2013/03/26/lisp-dead-alive/
"
（其实老 Lisp 的死去还有另外一个重要的原因，那就是因为早期的 Lisp 编译器生成
的代码效率非常低下。这个问题我留到下一篇博文再讲。）
"
【在 x****u 的大作中提到】
: 说他这种话的人，不知道OS是干嘛的，也不知道CPU是干嘛的，也不知道数字电路是干
: 嘛的。
: 不是说把高级语言特性往下放速度就会倍增的，这是基本常识，大多数情况下速度都要
: 慢一个数量级。
|
|
|
x****u
发帖数: 44466 | 51 Lisp放入内核态，整个堆栈，虚拟内存机制全都完蛋，放入CPU，流水线，分支预测等
等全都要完蛋。
至于编译质量低下还真不是大问题，现在的编译器前端只管翻译到中间代码，优化，机
器码生成和机器码优化都是统一的。
么?
【在 d*******r 的大作中提到】
: 高级特性往下放速度肯定不会增加了，主要是慢多少吧，有人用过那个Chez Scheme么?
: 我看王的这几篇blog，意思也是说，以前编译器写得不好，效能太差了，所以老Lisp不
: 好用
: http://www.yinwang.org/blog-cn/2013/03/26/lisp-dead-alive/
: "
: （其实老 Lisp 的死去还有另外一个重要的原因，那就是因为早期的 Lisp 编译器生成
: 的代码效率非常低下。这个问题我留到下一篇博文再讲。）
: "
|
d*******r
发帖数: 3299 | |
x****u
发帖数: 44466 | 53 比如Lisp进内核，内存管理就是大问题。内核栈不可换页，所以都非常的小，只能用C
小心翼翼的写代码。
【在 d*******r 的大作中提到】
: "全都完蛋" 具体是什么情况，还是不太理解
|
L***n
发帖数: 6727 | 54 nice idea, why not start working on one hobby OS project. I'm also
very intested in a "Lisp OS" and would be happy to help test, haha
【在 d*******r 的大作中提到】
: 那要搞个他想象的那种新的 "Lisp Machine" 风格的OS, 直接把C那一层都去掉，鼓励
: 只用一种高级语言 (e.g. Scheme). 现实不?
|
d*******r
发帖数: 3299 | 55 应该是挺好玩的 hobby project, 等有闲了再做吧，现在还得忙活着温饱
【在 L***n 的大作中提到】
: nice idea, why not start working on one hobby OS project. I'm also
: very intested in a "Lisp OS" and would be happy to help test, haha
|
z****e
发帖数: 54598 | 56 fp放一边不说，毕竟计算机大多数时候，尤其是用来赚钱的时候
都不是给scientific nerd用的，反而是给女人和gay用做艺术的成分比较多
所以一直都有种提案，希望把jvm直接融合到linux kernal里面去
linus不同意罢了，不过作为妥协，它认为，现在jvm已经可以跟linux无缝集成了
所以没有必要融合，作为市场上的尝试，其实android就是这么一个东西
【在 d*******r 的大作中提到】
: 那要搞个他想象的那种新的 "Lisp Machine" 风格的OS, 直接把C那一层都去掉，鼓励
: 只用一种高级语言 (e.g. Scheme). 现实不?
|
d*******r
发帖数: 3299 | 57 就是说把JVM放入Linux kernel也不是一bad idea咯？
JVM应该比Lisp的各种方言compiler复杂多了吧，龙猫说说这个idea靠谱不? 还是JVM应
该永远放在 user space？
【在 z****e 的大作中提到】
: fp放一边不说，毕竟计算机大多数时候，尤其是用来赚钱的时候
: 都不是给scientific nerd用的，反而是给女人和gay用做艺术的成分比较多
: 所以一直都有种提案，希望把jvm直接融合到linux kernal里面去
: linus不同意罢了，不过作为妥协，它认为，现在jvm已经可以跟linux无缝集成了
: 所以没有必要融合，作为市场上的尝试，其实android就是这么一个东西
|
x****u
发帖数: 44466 | 58 不可行。内核驱动没法最大效率的利用内存，性能上也无优势。
【在 d*******r 的大作中提到】
: 就是说把JVM放入Linux kernel也不是一bad idea咯？
: JVM应该比Lisp的各种方言compiler复杂多了吧，龙猫说说这个idea靠谱不? 还是JVM应
: 该永远放在 user space？
|
d*******r
发帖数: 3299 | 59 老赵什么看法
【在 x****u 的大作中提到】
: 不可行。内核驱动没法最大效率的利用内存，性能上也无优势。
|
s****y
发帖数: 38 | 60 正解，lisp machine底层实现性能不会好。
【在 x****u 的大作中提到】
: CPU的指令集设计和性能有极大关系，支持复杂指令会导致速度和主频指数级下降。
|
|
|
L***n
发帖数: 6727 | 61 当年被x86杀的屁滚尿流，在lisp machine上native执行的代码还不如
在x86上解释的快，这还是386的年代
【在 s****y 的大作中提到】
: 正解，lisp machine底层实现性能不会好。
|
z****e
发帖数: 54598 | 62 我也赞同不在内核里面实现
但是作为os一个整体，必需托管内存
而不是把这个问题推给app去解决
实际上早期的windows就这么做
早期几个版本的windows都自带微软自己的jvm
后来闹翻了之后，才不再这么做
distro其实也这么做，但是后来因为版权问题
所以现在才全部改为自带openjdk的安装包
其实macosx也曾经这么做过
不过不这么做的原因跟前面两个不一样
是因为apple的jvm做得比较烂，后来被oracle说服，放弃了自己的jvm
改为支持openjdk，从那以后，就不再自带jvm了
【在 d*******r 的大作中提到】
: 老赵什么看法
|
d*******r
发帖数: 3299 | 63 还有这么一段历史，受教了
【在 z****e 的大作中提到】
: 我也赞同不在内核里面实现
: 但是作为os一个整体，必需托管内存
: 而不是把这个问题推给app去解决
: 实际上早期的windows就这么做
: 早期几个版本的windows都自带微软自己的jvm
: 后来闹翻了之后，才不再这么做
: distro其实也这么做，但是后来因为版权问题
: 所以现在才全部改为自带openjdk的安装包
: 其实macosx也曾经这么做过
: 不过不这么做的原因跟前面两个不一样
|
x****u
发帖数: 44466 | 64 你说的这个叫捆绑，买一送一。
【在 z****e 的大作中提到】
: 我也赞同不在内核里面实现
: 但是作为os一个整体，必需托管内存
: 而不是把这个问题推给app去解决
: 实际上早期的windows就这么做
: 早期几个版本的windows都自带微软自己的jvm
: 后来闹翻了之后，才不再这么做
: distro其实也这么做，但是后来因为版权问题
: 所以现在才全部改为自带openjdk的安装包
: 其实macosx也曾经这么做过
: 不过不这么做的原因跟前面两个不一样
|
