Redian新闻
>
golang是第一个大规模multi-core, N:M thread model Language
avatar
golang是第一个大规模multi-core, N:M thread model Language# Programming - 葵花宝典
D*e
1
丝瓜络要多老的丝瓜才有?现在有些皮变黄了,可以摘下来再放老吗?等着翻地种别的
avatar
c*v
2
wdong 2015年说过这个关键的地方。
这几年下来,基本情况没update。
(1)
Golang 可以自动调度N任务在M kernel线程across P multi-cores。
这个不管做得好坏。难度是非常大的。
linux是1:1.
(2) Rust : https://doc.rust-lang.org/1.24.1/book/second-edition/ch16-01-
threads.html
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.
(3)
2012 Golang scheduler design spec
https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_
kqxDv3I3XMw/edit
avatar
L*A
3
什么是丝瓜络?
avatar
s*i
4
请教,这个特性是语言层面的还是底层实现的问题?其他语言有没有可能逐渐也实现这
个呢?
avatar
D*e
5
就是老丝瓜的瓤,洗碗用

【在 L****A 的大作中提到】
: 什么是丝瓜络?
avatar
c*v
6
理论上我觉得这应该是OS干的事。实现这个很难。
不管是谁.
一来spec难写。不知道该满足哪一类需求。
第二,就算spec写了。不管啥资源,task assignment时不时的就会冒出来NP hard啊。
那么只能用一些简单但是强壮的基本方法。写好以后,再回过头改问题的定义,甚至要
求程序员follow 所谓的goog practice。
From effective java:
The best way to write a robust, responsive, portable program is to ensure
that the average number of runnable threads is not significantly greater
than the number of processors. This leaves the thread scheduler with little
choice: it simply runs the runnable threads till they’re no longer runnable.
这个对scheduler的不信任不能说完全不合理。

【在 s*i 的大作中提到】
: 请教,这个特性是语言层面的还是底层实现的问题?其他语言有没有可能逐渐也实现这
: 个呢?

avatar
m*6
7
我们那里叫丝瓜经。
你等着翻地种其他菜的话,不值得等丝瓜络的。
1刀多的洗碗刷可以用N年了,
丝瓜络用不了多久就玩菜了,纯粹怀旧用用,不能当回事儿。
avatar
h*i
8
No.
Every languages worth mentioning today have these.

implementation

【在 c*******v 的大作中提到】
: wdong 2015年说过这个关键的地方。
: 这几年下来,基本情况没update。
: (1)
: Golang 可以自动调度N任务在M kernel线程across P multi-cores。
: 这个不管做得好坏。难度是非常大的。
: linux是1:1.
: (2) Rust : https://doc.rust-lang.org/1.24.1/book/second-edition/ch16-01-
: threads.html
: The green threading M:N model requires a larger language runtime to manage
: threads. As such, the Rust standard library only provides an implementation

avatar
y*8
9
皮要变黄变脆才行的,觉得可以摘下来放老的,放太阳下多晒晒应该能管用。

【在 D***e 的大作中提到】
: 丝瓜络要多老的丝瓜才有?现在有些皮变黄了,可以摘下来再放老吗?等着翻地种别的
: 。

avatar
g*t
10
(1)
Java by default自带是1:1的(自己写的不算。)。这源自于当初Solaris,linux没搞
定。
java跟着OS走。我查了一下,多年前这方面的论文还颇有一些。
以前java社区应该是有过1:N的。我记不确切了。
但是三层调度,java社区也好,别的社区也好,都是我没有见过的。
another example我贴过了。rust文档如下:
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.
(2)
Golang这个三层调度应用效果如何先不讲。
实事求是的讲,没有失败还是很厉害的。这条路可以说已经开出来了。
再过5年,精通golang性能调优的专家就会流行的。
就跟今日懂jvm的人类似。

【在 h*i 的大作中提到】
: No.
: Every languages worth mentioning today have these.
:
: implementation

avatar
y*8
11
我们也叫丝瓜巾!

【在 m**6 的大作中提到】
: 我们那里叫丝瓜经。
: 你等着翻地种其他菜的话,不值得等丝瓜络的。
: 1刀多的洗碗刷可以用N年了,
: 丝瓜络用不了多久就玩菜了,纯粹怀旧用用,不能当回事儿。

avatar
g*t
12
Java is 1:1, from reedit by a Phd in concurrency:
"
A thread pool does not let me have M stacks at a time. It only lets me have
N - the same number of OS threads. You cannot take a task running on a
threadpool thread and suspend it, can you? You can a goroutine or Erlang
process.
That's why it's thread pools aren't M:N - they only have N stacks. They're N
:N (so 1:1), with an extra queue of M jobs, but they aren't running until
there's space in the N OS threads.
Goroutines do not have the same problem as I've described, because they can
run M stacks at a time - M jobs can make progress towards meeting at the
barrier, and then cooperatively (so we don't need preemption here - they're
doing it cooperatively so not being preemptible isn't relevant here)
deschedule themselves while waiting at the barrier, allowing another of the
goroutines to be scheduled and to make progress.
Source: I wrote a PhD on concurrency and parallelism models and programming
language implementation, and I work at Oracle on Java virtual machines.
"

【在 h*i 的大作中提到】
: No.
: Every languages worth mentioning today have these.
:
: implementation

avatar
B*a
13
有一次在老墨店看到有卖丝瓜瓤子的,洗澡用

【在 D***e 的大作中提到】
: 就是老丝瓜的瓤,洗碗用
avatar
a*e
14
Haskell GHC 从 04 年就支持 N:M 调度了。
Go 这些年没啥好吹的才来吹 green thread / co-routine,因为之前它的 GC 太烂了。

implementation

【在 c*******v 的大作中提到】
: wdong 2015年说过这个关键的地方。
: 这几年下来,基本情况没update。
: (1)
: Golang 可以自动调度N任务在M kernel线程across P multi-cores。
: 这个不管做得好坏。难度是非常大的。
: linux是1:1.
: (2) Rust : https://doc.rust-lang.org/1.24.1/book/second-edition/ch16-01-
: threads.html
: The green threading M:N model requires a larger language runtime to manage
: threads. As such, the Rust standard library only provides an implementation

avatar
y*8
15
老美店也有。做成手套的形状,很漂亮的,就是价格不菲了。

【在 B*******a 的大作中提到】
: 有一次在老墨店看到有卖丝瓜瓤子的,洗澡用
avatar
h*i
16
No.
Why do you quote a stupid person who has not worked in any real application?
I said in this board a few weeks ago, "Don't listen to these stupid
recommendation about how many threads should be in your thread pool."
Listen to me: use thousands of threads in your pool.
The reason is simple, most modern programming is doing IO, so you block on
IO everywhere: network requests, database request, file system, EVERYWHERE.
You need those threads in your async thread pool, otherwise, you will
quickly run out of threads because all of them are waiting on something.
I know, you are not "supposed" to block in the "async" code, but NO, you
WILL be blocking in your async code, because all the low level stuff are
blocking.
Don't read stupid comments on the Internet, instead, build things and try
things yourself.

have
N
can

【在 g****t 的大作中提到】
: Java is 1:1, from reedit by a Phd in concurrency:
: "
: A thread pool does not let me have M stacks at a time. It only lets me have
: N - the same number of OS threads. You cannot take a task running on a
: threadpool thread and suspend it, can you? You can a goroutine or Erlang
: process.
: That's why it's thread pools aren't M:N - they only have N stacks. They're N
: :N (so 1:1), with an extra queue of M jobs, but they aren't running until
: there's space in the N OS threads.
: Goroutines do not have the same problem as I've described, because they can

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。