g****t
发帖数: 31659 | 1 刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。所
以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优化
。先天golang的设
置占优势。
这个说法似乎颇有道理，大家怎么看？ |
f******2
发帖数: 2455 | |
w**z
发帖数: 8232 | 3 我也看到了，java 每个线程给 4m stack. go routine idle 就不要。但go routine
啥都不干，开那么多有啥意义。 要在正真高并发，处理任务的时候比较才有意义。
：刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
：一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。
所以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优
化。先天golang的设 |
g****t
发帖数: 31659 | 4 Idle 的不占资源，这个似乎也是有意义的
如果这种情况确实是一个user case能让jvm无法给别的线程分资源的话
: 我也看到了，java 每个线程给 4m stack. go routine idle 就不要。
但go
routine
: 啥都不干，开那么多有啥意义。 要在正真高并发，处理任务的时候比较
才有意
义。
: ：刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为
golang可
以观察到
: ：一切信息，所以不需要分配资源的线程就不分配。jvm by default看不
到这些
信息。
: 所以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假
设条件
下的优
: 化。先天golang的设
【在 w**z 的大作中提到】
: 我也看到了，java 每个线程给 4m stack. go routine idle 就不要。但go routine
: 啥都不干，开那么多有啥意义。 要在正真高并发，处理任务的时候比较才有意义。
:
: ：刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
: ：一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。
: 所以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优
: 化。先天golang的设
|
g****t
发帖数: 31659 | 5 就是说不管 idle与否都4M
: jvm怎么看不到os线程了？
【在 f******2 的大作中提到】
: jvm怎么看不到os线程了？
|
M********t
发帖数: 5032 | 6 又不是真的给4m
page table做了个4m的entries 而已
实际用不了多少
【在 g****t 的大作中提到】
: 就是说不管 idle与否都4M
:
:
: jvm怎么看不到os线程了？
:
|
w***g
发帖数: 5958 | 7 你这个描述太抽象，我其实理解不了。你要有原文链接的话麻烦贴一下。
感觉跟王垠当年吹的ext3文件系统能自动优化所以没有碎片这套理论很像。
我感觉golang和jvm的runtime所谓的分配资源，都是按请求来的。请求多少
就分配多少，没啥观察到观察不到的。
【在 g****t 的大作中提到】
: 刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
: 一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。所
: 以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优化
: 。先天golang的设
: 置占优势。
: 这个说法似乎颇有道理，大家怎么看？
|
g****t
发帖数: 31659 | 8 我这不是描述抽象。是我压根不懂这些技术细节。
所以只能凭印象说一下。哈哈。原文里面是下面一段。
https://rcoh.me/posts/why-you-can-have-a-million-go-routines-but-only-1000-
java-threads/
Supporting truly massive concurrency requires another optimization: Only
schedule a thread when you know it can do useful work! If you’re running
that many threads, only a handful can be be doing useful work anyway. Go
facilitates this by integrating channels and the scheduler. If a goroutine
is waiting on a empty channel, the scheduler can see that and it won’t run
the Goroutine. Go goes one step further and actually sticks the mostly-idle
goroutines on their own operating system thread. This way the (hopefully
much smaller) number of active goroutines can be scheduled by one thread
while the millions of mostly-sleeping goroutines can be tended to separately
. This helps keep latency down.
Unless Java added language features that the scheduler could observe,
supporting intelligent scheduling would be impossible. However, you can
build runtime schedulers in “user space” that are aware of when a thread
can do work. This forms the basis for frameworks like Akka that can support
millions of actors6
: 你这个描述太抽象，我其实理解不了。你要有原文链接的话麻烦贴一下。
: 感觉跟王垠当年吹的ext3文件系统能自动优化所以没有碎片这套理论很像。
: 我感觉golang和jvm的runtime所谓的分配资源，都是按请求来的。请求多少
: 就分配多少，没啥观察到观察不到的。
【在 w***g 的大作中提到】
: 你这个描述太抽象，我其实理解不了。你要有原文链接的话麻烦贴一下。
: 感觉跟王垠当年吹的ext3文件系统能自动优化所以没有碎片这套理论很像。
: 我感觉golang和jvm的runtime所谓的分配资源，都是按请求来的。请求多少
: 就分配多少，没啥观察到观察不到的。
|
w***g
发帖数: 5958 | 9 massive concurrency本身是一个站不住脚的需求。
假设一台牛x的服务器，有两个U，每个64线程，一共128线程正在运行。
如果是操统线程，1/10 active，一共调度1280个线程，完全没有压力。
那么对于go来说，得12800个线程才称得上massive parallel。
而且最后cooperative threading在latency上拼不拼得过操统线程还
不一定。
run
idle
【在 g****t 的大作中提到】
: 我这不是描述抽象。是我压根不懂这些技术细节。
: 所以只能凭印象说一下。哈哈。原文里面是下面一段。
: https://rcoh.me/posts/why-you-can-have-a-million-go-routines-but-only-1000-
: java-threads/
: Supporting truly massive concurrency requires another optimization: Only
: schedule a thread when you know it can do useful work! If you’re running
: that many threads, only a handful can be be doing useful work anyway. Go
: facilitates this by integrating channels and the scheduler. If a goroutine
: is waiting on a empty channel, the scheduler can see that and it won’t run
: the Goroutine. Go goes one step further and actually sticks the mostly-idle
|
m*****n
发帖数: 3575 | 10 如果换作Alpha Go那种计算线程呢？
是不是只能每个核一个进程了？
【在 w***g 的大作中提到】
: massive concurrency本身是一个站不住脚的需求。
: 假设一台牛x的服务器，有两个U，每个64线程，一共128线程正在运行。
: 如果是操统线程，1/10 active，一共调度1280个线程，完全没有压力。
: 那么对于go来说，得12800个线程才称得上massive parallel。
: 而且最后cooperative threading在latency上拼不拼得过操统线程还
: 不一定。
:
: run
: idle
|
|
|
c********1
发帖数: 5269 | 11 听上来,Golang用callback function ,不是用thread
run
idle
【在 g****t 的大作中提到】
: 我这不是描述抽象。是我压根不懂这些技术细节。
: 所以只能凭印象说一下。哈哈。原文里面是下面一段。
: https://rcoh.me/posts/why-you-can-have-a-million-go-routines-but-only-1000-
: java-threads/
: Supporting truly massive concurrency requires another optimization: Only
: schedule a thread when you know it can do useful work! If you’re running
: that many threads, only a handful can be be doing useful work anyway. Go
: facilitates this by integrating channels and the scheduler. If a goroutine
: is waiting on a empty channel, the scheduler can see that and it won’t run
: the Goroutine. Go goes one step further and actually sticks the mostly-idle
|
w**z
发帖数: 8232 | 12 中文翻译版
https://mp.weixin.qq.com/s/v-Q5aOnYVj7l-kMQopkPLA
：我这不是描述抽象。是我压根不懂这些技术细节。
：所以只能凭印象说一下。哈哈。原文里面是下面一段。 |
s********k
发帖数: 6180 | 13 Goroutine主要在native thread上做了很细致粒度的，多个goroutine（所谓的G
structure）公用一个thread（M structure）。（具体的狗狗一下）
routine
察到
【在 w**z 的大作中提到】
: 我也看到了，java 每个线程给 4m stack. go routine idle 就不要。但go routine
: 啥都不干，开那么多有啥意义。 要在正真高并发，处理任务的时候比较才有意义。
:
: ：刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
: ：一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。
: 所以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优
: 化。先天golang的设
|
s********k
发帖数: 6180 | 14 http://morsmachine.dk/go-scheduler?spm=a2c5q.11423531.0.0.3d354fa0OblSm4
还是看这个
https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_
kqxDv3I3XMw/edit
还有这个
【在 s********k 的大作中提到】
: Goroutine主要在native thread上做了很细致粒度的，多个goroutine（所谓的G
: structure）公用一个thread（M structure）。（具体的狗狗一下）
:
: routine
: 察到
|
n******7
发帖数: 12463 | 15 不错，thx
【在 w**z 的大作中提到】
: 中文翻译版
: https://mp.weixin.qq.com/s/v-Q5aOnYVj7l-kMQopkPLA
:
: ：我这不是描述抽象。是我压根不懂这些技术细节。
: ：所以只能凭印象说一下。哈哈。原文里面是下面一段。
|
f*******t
发帖数: 7549 | 16 如果基于运行时记录预测哪个线程应该被执行，是不是能进一步优化性能 |
w***g
发帖数: 5958 | 17 这个对操统线程也适用，而且更一般化。
这种调度能给runtime的overhead极少，
所以预测其实很难做。
我感觉用在磁盘firmware上预测prefetch可能会比较管用。
即使是SSD也比CPU慢的多，预测中了提高会比较明显。
【在 f*******t 的大作中提到】
: 如果基于运行时记录预测哪个线程应该被执行，是不是能进一步优化性能
|
g****t
发帖数: 31659 | 18 你说的很对。
【在 w***g 的大作中提到】
: 这个对操统线程也适用，而且更一般化。
: 这种调度能给runtime的overhead极少，
: 所以预测其实很难做。
: 我感觉用在磁盘firmware上预测prefetch可能会比较管用。
: 即使是SSD也比CPU慢的多，预测中了提高会比较明显。
|
f*******t
发帖数: 7549 | 19 我觉得有可能做到。比如100台跑同质服务的分布式系统，挑其中几台做profiling，对
整个系统的性能影响不会很大。分析之后进行预测，通过config的形式部署到其它机器
上，然后再挑机器记录性能的改进和回归，通过A/B testing不断迭代。比如FB几十万
台前端服务器跑的都是一样的PHP代码，每降低0.x%的CPU就能节省以million计的成本。
当然我是从分布式系统角度看这个问题的，不知道单机做这个成本和收益的比例是多少。
【在 w***g 的大作中提到】
: 这个对操统线程也适用，而且更一般化。
: 这种调度能给runtime的overhead极少，
: 所以预测其实很难做。
: 我感觉用在磁盘firmware上预测prefetch可能会比较管用。
: 即使是SSD也比CPU慢的多，预测中了提高会比较明显。
|
g****t
发帖数: 31659 | 20 直接deep refeinforcement learning吧。迭代预测的话，你把里面的look up table改
成CNN，那就是deep RL.
多层的表格，好过一层摊开的大表
: 我觉得有可能做到。比如100台跑同质服务的分布式系统，挑其中几台做
profiling，对
: 整个系统的性能影响不会很大。分析之后进行预测，通过config的形式部署到其
它机器
: 上，然后再挑机器记录性能的改进和回归，通过A/B testing不断迭代。比如FB
几十万
: 台前端服务器跑的都是一样的PHP代码，每降低0.x%的CPU就能节省以million计
的成本。
: 当然我是从分布式系统角度看这个问题的，不知道单机做这个成本和收益的比例
是多少。
【在 f*******t 的大作中提到】
: 我觉得有可能做到。比如100台跑同质服务的分布式系统，挑其中几台做profiling，对
: 整个系统的性能影响不会很大。分析之后进行预测，通过config的形式部署到其它机器
: 上，然后再挑机器记录性能的改进和回归，通过A/B testing不断迭代。比如FB几十万
: 台前端服务器跑的都是一样的PHP代码，每降低0.x%的CPU就能节省以million计的成本。
: 当然我是从分布式系统角度看这个问题的，不知道单机做这个成本和收益的比例是多少。
|
|
|
f*******t
发帖数: 7549 | 21 不一定要deep learning吧，这种东西说不定简单的算一下avg和std就能搞定
【在 g****t 的大作中提到】
: 直接deep refeinforcement learning吧。迭代预测的话，你把里面的look up table改
: 成CNN，那就是deep RL.
: 多层的表格，好过一层摊开的大表
:
:
: 我觉得有可能做到。比如100台跑同质服务的分布式系统，挑其中几台做
: profiling，对
:
: 整个系统的性能影响不会很大。分析之后进行预测，通过config的形式部署到其
: 它机器
:
: 上，然后再挑机器记录性能的改进和回归，通过A/B testing不断迭代。比如FB
: 几十万
|
g****t
发帖数: 31659 | 22 Avg std可能要分段或者滚动计算才行。分段就相当于一层表格。效率可能不如多层表
格，就是DL
之前有过几个文献，本版讨论过。我觉得最新的一些文献的说法有道理。neural
network用折线非线性其实就是查表。那么
多层多表连起来，效率应该是比一层大表好。
: 不一定要deep learning吧，这种东西说不定简单的算一下avg和std就能
搞定
【在 f*******t 的大作中提到】
: 不一定要deep learning吧，这种东西说不定简单的算一下avg和std就能搞定
|
s*****V
发帖数: 21731 | 23 听到一种说法，coroutine自愿yield，用一个event loop, 可以处理上百万个用户线
程。
【在 w***g 的大作中提到】
: massive concurrency本身是一个站不住脚的需求。
: 假设一台牛x的服务器，有两个U，每个64线程，一共128线程正在运行。
: 如果是操统线程，1/10 active，一共调度1280个线程，完全没有压力。
: 那么对于go来说，得12800个线程才称得上massive parallel。
: 而且最后cooperative threading在latency上拼不拼得过操统线程还
: 不一定。
:
: run
: idle
|
T********i
发帖数: 2416 | 24 你才是胡算，同样throughput，cooperative threading 128线程当然拼得过1280操统
线程。同样的latency，throughput恐怕会大一倍。
如果变成12800线程，恐怕就会有数量级的差别了。
【在 w***g 的大作中提到】
: massive concurrency本身是一个站不住脚的需求。
: 假设一台牛x的服务器，有两个U，每个64线程，一共128线程正在运行。
: 如果是操统线程，1/10 active，一共调度1280个线程，完全没有压力。
: 那么对于go来说，得12800个线程才称得上massive parallel。
: 而且最后cooperative threading在latency上拼不拼得过操统线程还
: 不一定。
:
: run
: idle
|
w***g
发帖数: 5958 | 25 前提是百万个用户线程绝大多数都在等I/O。
用户线程只有在syscall的时候才会yield。如果正在跑的线程
开始算neural network了老也不syscall，别的线程就都会被挂起。
如果就是有这么多并行计算的需求，那么不管用操统线程还是coroutine
都无解。但一般来说，同样的计算任务和硬件，有一个最优线程数。
超过了性能也会下降。
go的套路是鼓励程序员起线程。所以很可能创造出来本来
并不需要的线程。有点没有问题创造问题也要解决的感觉。
写了一大段，说白了，其实最能发挥go的威力的是用go把nginx
重写一遍，能写的更漂亮。未必能比nginx快，但肯定比apache快。
go基本上就是让人能放飞了用epoll kqueue这些东西。
我吐的槽是，虽然牙膏厂挤了这么多年牙膏，CPU算力近十年还是
有显著增长的。和I/O相比，(可用于I/O的)CPU算力应该是更加富余了。
另一方面，和以前用nginx serve静态网页相比，现在的服务器
逻辑更加复杂计算量更加大。相比之下，epoll省下来那点算力
对提高服务器整体吞吐量的作用应该是在降低的。
(注意是epoll和操统线程比剩下来的算力，不是和poll比）
总的来说epoll的重要性本身就在降低。
go我不熟，发帖前在stack overflow验证了下，有错请指正。
Win 3.1的多个程序就是coroutine。到NT/95才有的真正的操统线程。
【在 s*****V 的大作中提到】
: 听到一种说法，coroutine自愿yield，用一个event loop, 可以处理上百万个用户线
: 程。
|
f******2
发帖数: 2455 | 26 这个思路我曾经想过，但是问题有一下两点：
1. 大部分情况基本的heuristic可能就够了；
2. 如果RL系统真的理论上better，怎么训练？哪里来的数据？
: 直接deep refeinforcement learning吧。迭代预测的话，你把里面的look up
table改
: 成CNN，那就是deep RL.
: 多层的表格，好过一层摊开的大表
: profiling，对
: 它机器
: 几十万
: 的成本。
: 是多少。
【在 g****t 的大作中提到】
: Avg std可能要分段或者滚动计算才行。分段就相当于一层表格。效率可能不如多层表
: 格，就是DL
: 之前有过几个文献，本版讨论过。我觉得最新的一些文献的说法有道理。neural
: network用折线非线性其实就是查表。那么
: 多层多表连起来，效率应该是比一层大表好。
:
:
: 不一定要deep learning吧，这种东西说不定简单的算一下avg和std就能
: 搞定
:
|
c********1
发帖数: 5269 | 27 一般来说.就是这样弄的
#1 用一个event loop
#2 coroutine自愿yield
【在 s*****V 的大作中提到】
: 听到一种说法，coroutine自愿yield，用一个event loop, 可以处理上百万个用户线
: 程。
|
w***g
发帖数: 5958 | 28 你是对的。
我的意思是，现在CPU快，操统调度1280线程也调度的过来。
如果这些线程主要就是等I/O，CPU可能都用不满。优化了也是白优化。
要demonstrate coop thread牛x，得起12800个线程，展示数量级差别才行。
【在 T********i 的大作中提到】
: 你才是胡算，同样throughput，cooperative threading 128线程当然拼得过1280操统
: 线程。同样的latency，throughput恐怕会大一倍。
: 如果变成12800线程，恐怕就会有数量级的差别了。
|
s*****V
发帖数: 21731 | 29 大牛太谦虚了，我就是听了一个Rob Pike的talk过来鬼扯两句。这说不定是鸡生蛋，蛋
生鸡的问题，现在牙膏厂不是出28核的cpu了么，单核性能到顶后，多核变成一个趋势
的话，go这种高并发的写法就成了天然的优势。
【在 w***g 的大作中提到】
: 前提是百万个用户线程绝大多数都在等I/O。
: 用户线程只有在syscall的时候才会yield。如果正在跑的线程
: 开始算neural network了老也不syscall，别的线程就都会被挂起。
: 如果就是有这么多并行计算的需求，那么不管用操统线程还是coroutine
: 都无解。但一般来说，同样的计算任务和硬件，有一个最优线程数。
: 超过了性能也会下降。
: go的套路是鼓励程序员起线程。所以很可能创造出来本来
: 并不需要的线程。有点没有问题创造问题也要解决的感觉。
: 写了一大段，说白了，其实最能发挥go的威力的是用go把nginx
: 重写一遍，能写的更漂亮。未必能比nginx快，但肯定比apache快。
|
f*******t
发帖数: 7549 | 30 现在Cpu越来越快，memory access可以算io了吗？
【在 w***g 的大作中提到】
: 你是对的。
: 我的意思是，现在CPU快，操统调度1280线程也调度的过来。
: 如果这些线程主要就是等I/O，CPU可能都用不满。优化了也是白优化。
: 要demonstrate coop thread牛x，得起12800个线程，展示数量级差别才行。
|
|
|
g*c
发帖数: 4510 | 31 对的，goroutine是green thread，或者叫做user level thread，不是os level
thread。
处理高并发的效率比thread高。
感觉这个是golang在服务器端成功的关键
【在 s********k 的大作中提到】
: Goroutine主要在native thread上做了很细致粒度的，多个goroutine（所谓的G
: structure）公用一个thread（M structure）。（具体的狗狗一下）
:
: routine
: 察到
|
m*****n
发帖数: 3575 | 32 听起来很像最近很流行的概念——纤程 coroutine
python3.6升级的重要模组就是async干的和这个差不多吧？
【在 g*c 的大作中提到】
: 对的，goroutine是green thread，或者叫做user level thread，不是os level
: thread。
: 处理高并发的效率比thread高。
: 感觉这个是golang在服务器端成功的关键
|
g*c
发帖数: 4510 | 33 是同一个东西，这个不是最近才流行吧，应该已经流行很久了，毕竟golang 09年诞生
的时候就设计了goroutine了
【在 m*****n 的大作中提到】
: 听起来很像最近很流行的概念——纤程 coroutine
: python3.6升级的重要模组就是async干的和这个差不多吧？
|
