当前在线人数9210
首页 - 分类讨论区 - 电脑网络 - 葵花宝典版 - 同主题阅读文章

此篇文章共收到打赏
0

  • 10
  • 20
  • 50
  • 100
您目前伪币余额:0
未名交友
[更多]
[更多]
coroutine CPU利用率最高
[版面:葵花宝典][首篇作者:TeacherWei] , 2021年07月20日05:54:41 ,2713次阅读,152次回复
来APP回复,赚取更多伪币 关注本站公众号:
[首页] [上页][下页][末页] [分页:1 2 3 4 5 6 7 8 ]
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 1 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 05:54:41 2021, 美东)

牺牲的是响应速度。这两者是不能兼得的。

80-90年代初的个人电脑操作系统都是coroutine。包括Windows 3.1和当时的MacOS。

到了Windows 95就是抢先多任务了。

系统和语言支持并发是应用的需求。是不可取代的。比如我的IoT操作系统平台,就是
我自己实现的一个coroutine的调度器。每个用户app的实例,都是一个虚拟进程/线程
。进程概念是必须的,有利于安全隔离,用沙箱确保虚拟进程不能互相干扰。而且一个
thread调度很多进程,进程杀死,一切资源自动GC了。

底层实现从coroutine改成thread/process。其实API是不用任何修改的。
--
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 100.]

 
dumbCoder
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 2 ]

发信人: dumbCoder (HumbleCoder 不懂就问-_-), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 11:49:38 2021, 美东)

最近 cooperative threading, coroutine, fiber thread 这一堆的流行.
不就是因为 CPU 太快了, 传统(Linux)内核里的 scheduler+thread 太低效了么?
特别是针对 IO bound 的所谓互联网公司后台的"大并发" server 程序.
然后一堆语言把 scheduler+thread 的工作弄到语言和用户空间而已,
这个大家有啥不能理解的?
--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 73.]

 
Caravel
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 3 ]

发信人: Caravel (克拉维尔), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 11:54:07 2021, 美东)

主动yield和被动yield的区别,操作系统的线程操作是被动yield,等于时间冷冻,把
所有状态保存下来,下次从新开始。这样可能并不是最优,因为活干了一半可能很
messy,换一个不相干的进来,cache miss什么也很多。主动yield把活干完了,就主动
去睡觉。

所以python虽然解释器是单线程,也可以写async code。

【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 最近 cooperative threading, coroutine, fiber thread 这一堆的流行.
: 不就是因为 CPU 太快了, 传统(Linux)内核里的 scheduler+thread 太低效了么?
: 特别是针对 IO bound 的所谓互联网公司后台的"大并发" server 程序.
: 然后一堆语言把 scheduler+thread 的工作弄到语言和用户空间而已,
: 这个大家有啥不能理解的?



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 73.]

 
dumbCoder
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 4 ]

发信人: dumbCoder (HumbleCoder 不懂就问-_-), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 12:00:32 2021, 美东)

说的是

每个主动yield的逻辑底层, 至少都有1个被动yield的逻辑来保证正确性.
就好像Python里面如果不yield, 底层OS会帮它yield.
Go的话, goroutine都是被动yield, 被Go runtime scheduler保证正确性.


【 在 Caravel (克拉维尔) 的大作中提到: 】
: 主动yield和被动yield的区别,操作系统的线程操作是被动yield,等于时间冷冻,把
: 所有状态保存下来,下次从新开始。这样可能并不是最优,因为活干了一半可能很
: messy,换一个不相干的进来,cache miss什么也很多。主动yield把活干完了,就主动
: 去睡觉。
: 所以python虽然解释器是单线程,也可以写async code。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 73.]

 
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 5 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 12:50:37 2021, 美东)

preemptive其实也有主动yield,很多system call的结果都会把当前线程放到waiting
queue里面,然后就去调度其他线程执行了。主要问题是这个context switch代价太高
而已。

coroutine降低的是context switch的代价而已。

对于我的IoT虚拟机而言,我不但希望自己调度,而且调度器还有kill任意coroutine的
需求。对于GC语言,kill掉任意coroutine,其资源必须能够被GC。也就是逻辑上和
kill一个process一样。能满足这个需求的凤毛麟角。有什么架构能干干净净kill
thread的?

--
※ 修改:·TeacherWei 於 Jul 20 12:52:13 2021 修改本文·[FROM: 100.]
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 100.]

 
chebyshev
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 6 ]

发信人: chebyshev (......), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 13:36:25 2021, 美东)

Go多了一层自动调度。
https://www.mitbbs.com/article_t/Programming/31544075.html

以前python也有什么green thread。功能类似吧。就是自己搞个能做调度的中间层。

N任务M thread之调度,按照rust的Doc说法是很难做的:
The green threading M:N model requires a larger language runtime to manage
threads. As such, the Rust standard library only provides an implementation
of 1:1 threading.

但是其实此文档并没说到关键问题上。
以我现在的理解,无论进程还是线程调度,以及资源自动切换分配等。
都有大批的启发式算法。那些启发式算法,实际上是和硬件磨合出来的。
简言之,离开特定的硬件,其是不成立的。

你把当代操作系统之new version,装到旧的CPU上,肯定性能非线性下降。corner
cases无数。

【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 说的是
: 每个主动yield的逻辑底层, 至少都有1个被动yield的逻辑来保证正确性.
: 就好像Python里面如果不yield, 底层OS会帮它yield.
: Go的话, goroutine都是被动yield, 被Go runtime scheduler保证正确性.




--
※ 修改:·chebyshev 於 Jul 20 13:41:07 2021 修改本文·[FROM: 72.]
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 72.]

 
netghost
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 7 ]

发信人: netghost (Up to Isomorphism), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 14:07:32 2021, 美东)

原因很簡單,I/O multiplexing 比multi threading 難寫。但是multi threading對於
併發要求高並行要求低的事情開銷太大。

問題是其實整個IT業界裏面,需要用coroutine來提高併發度的事情,少之又少,我可
以負責任地告訴大家,如果你的站點已經快到這個程度了,你most likely可以退休了。




【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 最近 cooperative threading, coroutine, fiber thread 这一堆的流行.
: 不就是因为 CPU 太快了, 传统(Linux)内核里的 scheduler+thread 太低效了么?
: 特别是针对 IO bound 的所谓互联网公司后台的"大并发" server 程序.
: 然后一堆语言把 scheduler+thread 的工作弄到语言和用户空间而已,
: 这个大家有啥不能理解的?



--
※ 修改:·netghost 于 Jul 20 14:40:20 2021 修改本文·[FROM: 71.]
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 71.]


 
netghost
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 8 ]

发信人: netghost (Up to Isomorphism), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 14:14:22 2021, 美东)

Golang的人之前就是搞C的人,知道C的核心地盤要搶不容易,所以不碰,帶來的好處就
是可以上GC,程序內建runtime調度執行單位。

Rust想法不一樣,都快形成一個教派了,天天叫着一統漿糊。自然沒法在語言裏面把調
度做死(M:N)。


【 在 chebyshev (......) 的大作中提到: 】
: Go多了一层自动调度。
: https://www.mitbbs.com/article_t/Programming/31544075.html
: 以前python也有什么green thread。功能类似吧。就是自己搞个能做调度的中间层。
: N任务M thread之调度,按照rust的Doc说法是很难做的:
: The green threading M:N model requires a larger language runtime to manage
: threads. As such, the Rust standard library only provides an
implementation
: of 1:1 threading.
: 但是其实此文档并没说到关键问题上。
: 以我现在的理解,无论进程还是线程调度,以及资源自动切换分配等。
: 都有大批的启发式算法。那些启发式算法,实际上是和硬件磨合出来的。
: ...................


--

※ 来源:·BBS 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 71.]

 
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 9 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 17:35:21 2021, 美东)

Coroutine用于IoT app引擎,还有一个重要作用就是每个app物理上应该都是一个独立
的process。

而process和函数function的区别在于,process是一个死循环的函数。

迄今为止,其他IoT app的架构还都是只允许开发过把瘾就死的函数。所谓的立即返回
的lambda function。因为图灵不完备就要创造几十个新概念,各种反人性之后依然图
灵完备存疑。

--
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 100.]

 
dumbCoder
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 10 ]

发信人: dumbCoder (HumbleCoder 不懂就问-_-), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 20:35:55 2021, 美东)

我看最后大家都爱自己写scheduler, 我做game server时候也是自己schedule.
写个不那么通用的 scheduler 其实不难,
其实就是在一个 underlying thread 里调用自己定义的运行单元.
underlying thread可以是C/C++ pthread, 也可以是GO goroutine,
自己定义的运行单元可以是 function, callback 啥的.
好比 Linux OS 就是把我们的 main 函数当运行单元来 schedule.


【 在 TeacherWei (TW) 的大作中提到: 】
: Coroutine用于IoT app引擎,还有一个重要作用就是每个app物理上应该都是一个独立
: 的process。
: 而process和函数function的区别在于,process是一个死循环的函数。
: 迄今为止,其他IoT app的架构还都是只允许开发过把瘾就死的函数。所谓的立即返回
: 的lambda function。因为图灵不完备就要创造几十个新概念,各种反人性之后依然图
: 灵完备存疑。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 73.]

 
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 11 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 20:47:03 2021, 美东)

我的这套架构,10年前就确定了。迄今为止,整个行业这么多人,砸了成百上千亿美金
,也没人想到要做一个图灵完备的process。扯了这么多蛋,就是不让开发者去写main
函数。

我被授予的那个5年前的专利,表面看来是重新发明了树结构,实质上是对我允许别人
写main函数的奖励。

这个世界,就是这么诡异。


【 在 dumbCoder(HumbleCoder 不懂就问-_-) 的大作中提到: 】
<br>: 我看最后大家都爱自己写scheduler, 我做game server时候也是自己schedule.
<br>: 写个不那么通用的 scheduler 其实不难,
<br>: 其实就是在一个 underlying thread 里调用自己定义的运行单元.
<br>: underlying thread可以是C/C   pthread, 也可以是GO goroutine,
<br>: 自己定义的运行单元可以是 function, callback 啥的.
<br>: 好比 Linux OS 就是把我们的 main 函数当运行单元来 schedule.
<br>
--
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 100.]

 
Caravel
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 12 ]

发信人: Caravel (克拉维尔), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 21:10:03 2021, 美东)

如果工作就是调包,是很没意思的,长此以往,马工这个行业可能就消亡了。

而实际情况是,会不停的造轮子,新一代不会甘心就用前人的轮子,会不停的发明新的
语言,继承或者部分继承老的语言。这样也可以保持程序员的创造性。只要人类的人口
保持增长,这个模式就没有问题。总有足够多的人把老问题掌握了再改进。


【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 我看最后大家都爱自己写scheduler, 我做game server时候也是自己schedule.
: 写个不那么通用的 scheduler 其实不难,
: 其实就是在一个 underlying thread 里调用自己定义的运行单元.
: underlying thread可以是C/C++ pthread, 也可以是GO goroutine,
: 自己定义的运行单元可以是 function, callback 啥的.
: 好比 Linux OS 就是把我们的 main 函数当运行单元来 schedule.



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 73.]

 
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 13 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 21:27:44 2021, 美东)

你们还是太年轻,太阳底下没有新鲜事儿。coroutine是80年代的流行技术。你们没做
过DOS和Windows 3.1编程,没有深刻印象而已。

80年代是我从小学到中学的年代,是一个美好的年代。

我做了这么多事情,基本都是70-80年代的技术。把最近20年的垃圾都丢掉,很多问题
就能简化10倍了。

【 在 Caravel (克拉维尔) 的大作中提到: 】
: 如果工作就是调包,是很没意思的,长此以往,马工这个行业可能就消亡了。
: 而实际情况是,会不停的造轮子,新一代不会甘心就用前人的轮子,会不停的发明新的
: 语言,继承或者部分继承老的语言。这样也可以保持程序员的创造性。只要人类的人口
: 保持增长,这个模式就没有问题。总有足够多的人把老问题掌握了再改进。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 100.]

 
bihai
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 14 ]

发信人: bihai (学得不好), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Tue Jul 20 23:33:29 2021, 美东)

过去有个知识我不清楚了,在80年代,DOS时代的芯片,和现在Linux但是i7比较,发生
硬件中断的时候,要把当前的IP放到堆栈上。这个是哪个堆栈?现在多任务了,每个进
程都有一个堆栈了。现在有什么改变吗?


【 在 TeacherWei (TW) 的大作中提到: 】
: 你们还是太年轻,太阳底下没有新鲜事儿。coroutine是80年代的流行技术。你们没做
: 过DOS和Windows 3.1编程,没有深刻印象而已。
: 80年代是我从小学到中学的年代,是一个美好的年代。
: 我做了这么多事情,基本都是70-80年代的技术。把最近20年的垃圾都丢掉,很多问题
: 就能简化10倍了。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 2601:647:4d00:a]

 
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 15 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Wed Jul 21 00:07:07 2021, 美东)

Intel的硬件逐渐为现代OS做了很多修改。

具体比较复杂。你可以搜一下memory translation和CPU ring。

简单说,中断可能会改变保护优先级,也就是CPU ring。在服务中断的时候,如果ring
改变,硬件会自动切换stack。


【 在 bihai(学得不好) 的大作中提到: 】
<br>: 过去有个知识我不清楚了,在80年代,DOS时代的芯片,和现在Linux但是i7比较
,发生
<br>: 硬件中断的时候,要把当前的IP放到堆栈上。这个是哪个堆栈?现在多任务了,
每个进
<br>: 程都有一个堆栈了。现在有什么改变吗?
<br>
--
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 100.]

 
minquan
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 16 ]

发信人: minquan (三民主义), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Wed Jul 21 00:12:52 2021, 美东)

我还记得QBasic最喜欢写goto

【 在 TeacherWei (TW) 的大作中提到: 】
: 你们还是太年轻,太阳底下没有新鲜事儿。coroutine是80年代的流行技术。你们没做
: 过DOS和Windows 3.1编程,没有深刻印象而已。
: 80年代是我从小学到中学的年代,是一个美好的年代。
: 我做了这么多事情,基本都是70-80年代的技术。把最近20年的垃圾都丢掉,很多问题
: 就能简化10倍了。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 95.]

 
dumbCoder
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 17 ]

发信人: dumbCoder (HumbleCoder 不懂就问-_-), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Wed Jul 21 12:57:57 2021, 美东)

新一代造的新流行的轮子, 可能大部分确实是垃圾.
为啥? 我长期观察思考的结论是: 能推广开并流行的"时髦"技术,
可能不是啥好技术,只是推广者资源多,推的”时髦“技术能忽悠人入坑.
总有一轮轮新技术来了又走,这里 前端, DevOps/infra 是重灾区.

所以我比较同意老魏或者netghost的观点: 没啥有用的新技术...
工业界就是时尚界...

参考这个,现在工业界就是乱造复杂的垃圾技术:
Jonathan Blow - Preventing the Collapse of Civilization
https://www.youtube.com/watch?v=pW-SOdj4Kkk


【 在 Caravel (克拉维尔) 的大作中提到: 】
: 如果工作就是调包,是很没意思的,长此以往,马工这个行业可能就消亡了。
: 而实际情况是,会不停的造轮子,新一代不会甘心就用前人的轮子,会不停的发明新的
: 语言,继承或者部分继承老的语言。这样也可以保持程序员的创造性。只要人类的人口
: 保持增长,这个模式就没有问题。总有足够多的人把老问题掌握了再改进。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 73.]

 
Caravel
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 18 ]

发信人: Caravel (克拉维尔), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Wed Jul 21 13:05:24 2021, 美东)

你们没有明白我的意思。

即使不是新鲜的东西,新一代也会喜欢自己打造而不是用旧的。因为创造是学习的唯一
办法,假设世界上再也不搞新语言了,那很快PL language的那一套methodology就会被
遗忘,最终就是真正需要的时候也不会有人再会使用。


【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 新一代造的新流行的轮子, 可能大部分确实是垃圾.
: 为啥? 我长期观察思考的结论是: 能推广开并流行的"时髦"技术,
: 可能不是啥好技术,只是推广者资源多,推的”时髦“技术能忽悠人入坑.
: 总有一轮轮新技术来了又走,这里 前端, DevOps/infra 是重灾区.
: 所以我比较同意老魏或者netghost的观点: 没啥有用的新技术...
: 工业界就是时尚界...
: 参考这个,现在工业界就是乱造复杂的垃圾技术:
: Jonathan Blow - Preventing the Collapse of Civilization
: https://www.youtube.com/watch?v=pW-SOdj4Kkk



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 73.]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 19 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Wed Jul 21 13:36:17 2021, 美东)

学习就是创造。这个说法不错。这就是阴阳易理。你读古文了吧?

旧的就是新的,新的就是旧的。但是除process philosophy可解释的现象之外。也有本
质性上不可解释的突破出现。所以哲学有两类。一类是阴阳易理,一类是莱布尼兹精妙
无比的逻辑单子论。

所以OS之发展除了evolving process,也必有突破性的关键节点。以并发而言,关键节
点之一就是定义concurrency 之terminology 与notions来frame住问题域的那个文章。

若要从更好的角度考虑此类问题。必须有notions之新突破。一个可以尝试的方向我认
为就是把function call和stack分开。



【 在 Caravel(克拉维尔) 的大作中提到: 】
<br>: 你们没有明白我的意思。
<br>: 即使不是新鲜的东西,新一代也会喜欢自己打造而不是用旧的。因为创造是学习
的唯一
<br>: 办法,假设世界上再也不搞新语言了,那很快PL language的那一套methodology
就会被
<br>: 遗忘,最终就是真正需要的时候也不会有人再会使用。
<br>
--
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 2607:fb90:1cd0:]

 
Caravel
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 20 ]

发信人: Caravel (克拉维尔), 信区: Programming
标  题: Re: coroutine CPU利用率最高
发信站: BBS 未名空间站 (Wed Jul 21 13:43:38 2021, 美东)

function call 和stack紧密联系是因为OS需要随时把process swap出来吧还有历史依
赖,其实并不是必须的,如果memory极大丰富,也可以用一个图来实现。call的时候生
成一个新的图的节点,call 完了把结果放在一个节点里让parent去取。


【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 学习就是创造。这个说法不错。这就是阴阳易理。你读古文了吧?
: 旧的就是新的,新的就是旧的。但是除process philosophy可解释的现象之外。也有本
: 质性上不可解释的突破出现。所以哲学有两类。一类是阴阳易理,一类是莱布尼兹精妙
: 无比的逻辑单子论。
: 所以OS之发展除了evolving process,也必有突破性的关键节点。以并发而言,关键节
: 点之一就是定义concurrency 之terminology 与notions来frame住问题域的那个文章。
: 若要从更好的角度考虑此类问题。必须有notions之新突破。一个可以尝试的方向我认
: 为就是把function call和stack分开。
: <br>: 你们没有明白我的意思。
: <br>: 即使不是新鲜的东西,新一代也会喜欢自己打造而不是用旧的。因为创造是学习
: ...................




--
※ 修改:·Caravel 於 Jul 21 13:44:46 2021 修改本文·[FROM: 73.]
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 73.]

[首页] [上页][下页][末页] [分页:1 2 3 4 5 6 7 8 ]
[快速返回] [ 进入葵花宝典讨论区] [返回顶部]
回复文章
标题:
内 容:

未名交友
将您的链接放在这儿

友情链接


 

Site Map - Contact Us - Terms and Conditions - Privacy Policy

版权所有,未名空间(mitbbs.com),since 1996