|
|---|
|
|
|
|
|
|
g****t
发帖数: 31659 | 1 调度问题很多都是NP. 例如10个卡车去三个仓库拿货送到20户人家。一个普遍的错觉是
，你propose的最优解，需要卡车都在忙。不然的话，根据连续性直觉，卡车多一点努
力就可以把货更快的送达。聪明人最容易有这种错觉。实际上NP问题的空间往往是非常
ugly的刺猬状不连续形状。多一点努力，会导致约束不满足，例如错过拿货的时间窗口
时有发生。
民营公司小老板觉得手下工人不能闲着，是一样的道理。我做这类问题，也经常用这个
点糊弄人。就说NP算法只能给次优解，但是你看机器都用满了对吧。这就跟咱们大家看
cpu几个核是不是跑满了100%，其实是类似的。 | h*i
发帖数: 3446 | 2 cpu跑满了不说明都在干正事。
当thread pool太小，没有足够thread的时候，你会发现这个时候CPU是100%的，但一切
都停滞了，没有任何进展。因为CPU在100%地作context switching， 但所有thread都
在等IO.
这就是我说的，不要相信作底层的这些人给你的建议：“thread pool size should be
less than the number of cores".
他们关心的问题和你关心的问题可能完全不同。他们关心throughout, 而你可能关心
latency.
如果你关心latency, 要信我基于现实经验得出的结论：thread pool size should be
in the thousands if you are supporting a large number of *human* users.
相信OS，现代的OS调度几千个thread没有任何压力。
在IO很多的应用，context switch的开销与IO的开销比起来可以忽略不计，与thread
pool太小带来的大问题比起来，context switch cost都不算啥。
【在 g****t 的大作中提到】
: 调度问题很多都是NP. 例如10个卡车去三个仓库拿货送到20户人家。一个普遍的错觉是
: ，你propose的最优解，需要卡车都在忙。不然的话，根据连续性直觉，卡车多一点努
: 力就可以把货更快的送达。聪明人最容易有这种错觉。实际上NP问题的空间往往是非常
: ugly的刺猬状不连续形状。多一点努力，会导致约束不满足，例如错过拿货的时间窗口
: 时有发生。
: 民营公司小老板觉得手下工人不能闲着，是一样的道理。我做这类问题，也经常用这个
: 点糊弄人。就说NP算法只能给次优解，但是你看机器都用满了对吧。这就跟咱们大家看
: cpu几个核是不是跑满了100%，其实是类似的。
| g****t
发帖数: 31659 | 3 我其实并不关心具体调度的问题。对此问题有自己思考的java人员到处都是，招一个很
快捷。
每个人都有自己的办法。我举这个例子的意思其实是。假如只看cpu 0%，100%。那是看
不出来调度的区别的。
be
be
【在 h*i 的大作中提到】
: cpu跑满了不说明都在干正事。
: 当thread pool太小，没有足够thread的时候，你会发现这个时候CPU是100%的，但一切
: 都停滞了，没有任何进展。因为CPU在100%地作context switching， 但所有thread都
: 在等IO.
: 这就是我说的，不要相信作底层的这些人给你的建议：“thread pool size should be
: less than the number of cores".
: 他们关心的问题和你关心的问题可能完全不同。他们关心throughout, 而你可能关心
: latency.
: 如果你关心latency, 要信我基于现实经验得出的结论：thread pool size should be
: in the thousands if you are supporting a large number of *human* users.
|
|
|
|
|
|
|
|
