话说老兄觉得Golang现在没法pin to core，不识NUMA，这正是大好机会啊，你要是能 够参与这方面的工作岂不是立马就大包裹了.看问题角度要不同嘛，你看到一个东西烂 ，但是还很受欢迎，不要去质疑为什么烂还收欢迎，要去想为啥这么烂还能收欢迎，我稍微改进下岂不是可以日进斗金。这样想大包裹自然来。
// scanobject scans the object starting at b, adding pointers to gcw. // b must point to the beginning of a heap object or an oblet. // scanobject consults the GC bitmap for the pointer mask and the // spans for the size of the object. // //go:nowritebarrier func scanobject(b uintptr, gcw *gcWork) { // Note that arena_used may change concurrently during // scanobject and hence scanobject may encounter a pointer to // a newly allocated heap object that is *not* in // [start,used). It will not mark this object; however, we // know that it was just installed by a mutator, which means // that mutator will execute a write barrier and take care of // marking it. This is even more pronounced on relaxed memory // architectures since we access arena_used without barriers // or synchronization, but the same logic applies.
...
// Work here is duplicated in scanblock and above. // If you make changes here, make changes there too. obj := *(*uintptr)(unsafe.Pointer(b + i)) ===> this line caused cache miss?
// At this point we have extracted the next potential pointer. // Check if it points into heap and not back at the current object. if obj != 0 && arena_start <= obj && obj < arena_used && obj-b >= n { // Mark the object. if obj, hbits, span, objIndex := heapBitsForObject( obj, b, i); obj != 0 { greyobject(obj, b, i, hbits, span, gcw, objIndex) } }
【 在 magagop (magagop) 的大作中提到: 】 : 罪魁祸首找到了：obj := *(*uintptr)(unsafe.Pointer(b + i)) : // scanobject scans the object starting at b, adding pointers to gcw. : // b must point to the beginning of a heap object or an oblet. : // scanobject consults the GC bitmap for the pointer mask and the : // spans for the size of the object. : // : //go:nowritebarrier : func scanobject(b uintptr, gcw *gcWork) { : // Note that arena_used may change concurrently during : // scanobject and hence scanobject may encounter a pointer to : ...................
【 在 magagop (magagop) 的大作中提到: 】 : 罪魁祸首找到了：obj := *(*uintptr)(unsafe.Pointer(b + i)) : // scanobject scans the object starting at b, adding pointers to gcw. : // b must point to the beginning of a heap object or an oblet. : // scanobject consults the GC bitmap for the pointer mask and the : // spans for the size of the object. : // : //go:nowritebarrier : func scanobject(b uintptr, gcw *gcWork) { : // Note that arena_used may change concurrently during : // scanobject and hence scanobject may encounter a pointer to : ...................
gc作者之一在这里https://groups.google.com/forum/m/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8 【 在 magagop(magagop) 的大作中提到: 】 <br>: 罪魁祸首找到了：obj := *(*uintptr)(unsafe.Pointer(b i)) <br>: // scanobject scans the object starting at b, adding pointers to gcw. <br>: // b must point to the beginning of a heap object or an oblet. <br>: // scanobject consults the GC bitmap for the pointer mask and the <br>: // spans for the size of the object. <br>: // <br>: //go:nowritebarrier <br>: func scanobject(b uintptr, gcw *gcWork) { <br>: // Note that arena_used may change concurrently during <br>: // scanobject and hence scanobject may encounter a pointer to : ................... <br>
做大规模项目 human is always the least scalable in your system 【 在 magagop (magagop) 的大作中提到: 】 : 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。 : 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为 : 都这么做了 : 只有亚麻和阿里是奇葩。
The main concepts in Go runtime are: M - OS thread (Machine). P - Logical CPU (Processor), there are exactly GOMAXPROCS P's. G - Goroutine. Netpoll - network poller (epoll descriptor). RunQ - scheduler queue with runnable G's. MHeap - global memory allocator state (contains central caches and free spans). MCache - per-P memory allocator cache. GC - garbage collector.
Current system architecture can be depicted as follows: Runtime does not try hard to ensure any locality, resources like P's and M's are pooled. Runtime is not aware of system topology. MCache is tied to P, and this provides some locality. But then P is not tied to M, so this * locality is easily destroyable*. New G's are generally submitted to the local RunQ, but once again P is not tied to M. When an M returns from a syscall quickly, it tries to re-acquire the same P it used before the syscall.
如果本来就是在VM上面再加pod上运行container，这个NUMA的作用还会很大吗？因为没法控制底层的OS，golang也很难做好scheduler把？ 【 在 magagop (magagop) 的大作中提到: 】 : 这里面讲了，为什么goroutine太多，在多路众核处理器上会大量造成cache-line miss : 和ping-pong效应。我们目前最强的机器是2路200+核心16个内存控制器，还没有测试， : 估计golang性能因为scheduling会很难看。做处理器的最怕跨路访问内存，一个load应 : 该有200~300ns延时，再加上超标量，相当于等待成百上千条指令啊，性能下降10倍算 : 少的。 : The main concepts in Go runtime are: : M - OS thread (Machine). : P - Logical CPU (Processor), there are exactly GOMAXPROCS P's. : G - Goroutine. : Netpoll - network poller (epoll descriptor). : ...................
你目前的实验室基于一个200+核心直接run bare golang的http server？但是实际上很多golang打包container的都是基于pod的，可以试一下k8s，比如你开# of core 个VM ？然后pin每个VM到一个core成为一个node，再每个node上再开2个pod？
所以你原来的测试是1个http server 开N个goroutine，现在变成每个pod上开一个http server，就应该是1个http server开N/200/2个goroutine
这样的scheduler问题就完全变了。不知道效果如何 【 在 magagop (magagop) 的大作中提到: 】 : 这里面讲了，为什么goroutine太多，在多路众核处理器上会大量造成cache-line miss : 和ping-pong效应。我们目前最强的机器是2路200+核心16个内存控制器，还没有测试， : 估计golang性能因为scheduling会很难看。做处理器的最怕跨路访问内存，一个load应 : 该有200~300ns延时，再加上超标量，相当于等待成百上千条指令啊，性能下降10倍算 : 少的。 : The main concepts in Go runtime are: : M - OS thread (Machine). : P - Logical CPU (Processor), there are exactly GOMAXPROCS P's. : G - Goroutine. : Netpoll - network poller (epoll descriptor). : ...................
一代架構了。
這使我對golang寫的多核應用程序性能產生懷疑：一個http server在48核處理器上居
然搞出124個threads，而且沒有pin to core，不識別numa，簡單靜態文件性能還沒有
nginx的零頭多，75% CPU都是idle，有失golang的水準。
這讓我想到了EE工程師的悲哀：世界上硬件CPU公司屈指可數，最牛的CPU公司性能比最差的快也不到一倍。而不合格的軟件工程師寫的爛程序糟蹋多核CPU，性能可能下降上
百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件開發部門不停的refactoring，翻修輪子製造工作崗位，才能保證軟件質量和性能。這
樣對於優秀的硬件工程師，跳槽也就一兩家公司競爭offer，而同樣優秀的軟件工程師
會有十幾家或更多公司競爭，包裹大幾倍就成了正常的市場現象。
pandas和keras用的人最多。下里巴人最好找工作。
【在 magagop(magagop)的大作中提到：】
：軟件設計太重要了，今天測試golang algernon http server靜態文件性能，比nginx差了幾十倍以上。在我們硬件CPU領域，別說差幾倍，性能提升5%都叫大改進，可以更新
：一代架構了。
以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞硬件的
功不可没
【 在 magagop (magagop) 的大作中提到: 】
: 軟件設計太重要了，今天測試golang algernon http server靜態文件性能，比nginx差
: 了幾十倍以上。在我們硬件CPU領域，別說差幾倍，性能提升5%都叫大改進，可以更新
: 一代架構了。
: 這使我對golang寫的多核應用程序性能產生懷疑：一個http server在48核處理器上居
: 然搞出124個threads，而且沒有pin to core，不識別numa，簡單靜態文件性能還沒有
: nginx的零頭多，75% CPU都是idle，有失golang的水準。
: 這讓我想到了EE工程師的悲哀：世界上硬件CPU公司屈指可數，最牛的CPU公司性能比最
: 差的快也不到一倍。而不合格的軟件工程師寫的爛程序糟蹋多核CPU，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
: ...................
只要比python快几倍就可以了。不和c plus比。
现在语言的设计要讨好程序员，不然出门就是死。
在这个程序员民主化进程中，唯一的例外是basic.
Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
不是没有道理的。
【 在 nchip(脑残芯) 的大作中提到: 】
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者c.
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞
硬件的
: 功不可没
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。
: 现在语言的设计要讨好程序员，不然出门就是死。
: 在这个程序员民主化进程中，唯一的例外是basic.
: Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
: 不是没有道理的。
:
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者
: c.
:
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞
: 硬件的
:
: 功不可没
: ...................
http://time.com/69316/basic/
Basic: the language that made computers personal
I would lik to say:
DNN: the algorithm that made data analysis personal
【 在 guvest(我爱你老婆Anna) 的大作中提到: 】
<br>: 以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。
<br>: 现在语言的设计要讨好程序员，不然出门就是死。
<br>: 在这个程序员民主化进程中，唯一的例外是basic.
<br>: Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
<br>: 不是没有道理的。
<br>: c.
<br>: 硬件的
<br>
【 在 nchip (脑残芯) 的大作中提到: 】
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者c.
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞硬件的
: 功不可没
改吧 你提这种问题没意思的很
搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太多，可能性无限。
硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
件成本算上，而且这个成本是和规模一起放大的。
你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
另外nginx本来就是俄罗斯人搞的，在一个领域追求性能极致，golang是几个人创造工
具创造市场给自己保住饭碗，你用的更不知道是谁写的自己吹牛用的，跟nginx这样在
市场中证明的肯定没法比。
【 在 magagop (magagop) 的大作中提到: 】
: 軟件設計太重要了，今天測試golang algernon http server靜態文件性能，比nginx差
: 了幾十倍以上。在我們硬件CPU領域，別說差幾倍，性能提升5%都叫大改進，可以更新
: 一代架構了。
: 這使我對golang寫的多核應用程序性能產生懷疑：一個http server在48核處理器上居
: 然搞出124個threads，而且沒有pin to core，不識別numa，簡單靜態文件性能還沒有
: nginx的零頭多，75% CPU都是idle，有失golang的水準。
: 這讓我想到了EE工程師的悲哀：世界上硬件CPU公司屈指可數，最牛的CPU公司性能比最
: 差的快也不到一倍。而不合格的軟件工程師寫的爛程序糟蹋多核CPU，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
: ...................
【 在 dracodoc (david) 的大作中提到: 】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
: ...................
求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個就像drystone測試，一般都選最簡單的應用。
【 在 sunshineboy(阳光男孩) 的大作中提到: 】
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
nginx改吧
: 改吧 你提这种问题没意思的很
【在 wdong(万事休)的大作中提到：】
：软件也是，c的性能被numpy糟蹋，numpy被pandas糟蹋，tensorflow被keras糟蹋，
：pandas和keras用的人最多。下里巴人最好找工作。
有可無的都被砍掉，於是硬件CPU廠家的性能差距越來越小。而軟件互聯網領域開發要
求糙快猛，實現同樣的功能，性能差異極大，導致各種方便麵語言橫行，golang是一個，python更差，java也不咋滴。
我認為主要原因不是golang、python、java這些語言爛，而是用這些語言的大部分程序員普遍缺乏軟件效率和CPU架構的基本常識，寫的東西爛。但這些並不妨礙他們的
package大，福利更好。因為硬件領域狡兔死獵狗烹，做得太穩定就沒工作了。
【 在 dracodoc(david) 的大作中提到: 】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得
先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
: ...................
方。
【 在 magagop (magagop) 的大作中提到: 】
: 就是這種簡單到不行的功能，golang algernon都沒做好，我不是做互聯網的，老闆要
: 求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個
: 就像drystone測試，一般都選最簡單的應用。
:
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
: nginx改吧
:
: 改吧 你提这种问题没意思的很
:
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: Can we put go binary server behind the nginx ?
的scale成本線性增加是scale-out，但多核處理器設計必須要考慮scale-up，就是在同樣內存地址空間上爆核心，問題很多，不容易提升。另外MPI算scale-out，OpenMP是
scale-up。互聯網基本是scale-out，傳統數據庫是scale-up。CPU設計兩個都需要考慮。
【 在 dracodoc(david) 的大作中提到: 】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得
先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
: ...................
加油吧，有空去龟版看看，里面氛转码围很好的
爱你宝贝
【 在 magagop (magagop) 的大作中提到: 】
: 互聯網領域講究一個月上線，勉強完成功能，然後不斷改進提高性能，提升空間有一百
: 倍以上。硬件正好相反，用幾年時間設計，一旦發布，靠固件和微指令性能提升空間只
: 有幾個percent，如果出問題（meltdown）新固件性能下降卻很大。這就是我感嘆的地
: 方。
其实你自己不就是在做这种类型的工作吗？我的理解，你做的工作是系统软件优化，
对吧?
【 在 magagop (magagop) 的大作中提到: 】
: 軟件設計太重要了，今天測試golang algernon http server靜態文件性能，比nginx差
: 了幾十倍以上。在我們硬件CPU領域，別說差幾倍，性能提升5%都叫大改進，可以更新
: 一代架構了。
: 這使我對golang寫的多核應用程序性能產生懷疑：一個http server在48核處理器上居
: 然搞出124個threads，而且沒有pin to core，不識別numa，簡單靜態文件性能還沒有
: nginx的零頭多，75% CPU都是idle，有失golang的水準。
: 這讓我想到了EE工程師的悲哀：世界上硬件CPU公司屈指可數，最牛的CPU公司性能比最
: 差的快也不到一倍。而不合格的軟件工程師寫的爛程序糟蹋多核CPU，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
: ...................
【 在 wdong(万事休) 的大作中提到: 】
: 可以的，但是该慢还是慢啊。我现在全线从apache2转nginx了。
lz你比较各啥。
性能跟nginx相差不大https://www.reddit.com/r/golang/comments/28so0e/go_networking_performance_vs_nginx/
这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多少钱途，因为nginx已经push到极限了，很难有余地做的更好
软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以开始个项目，但那根本不是产品
【 在 magagop (magagop) 的大作中提到: 】
: 就是這種簡單到不行的功能，golang algernon都沒做好，我不是做互聯網的，老闆要
: 求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個
: 就像drystone測試，一般都選最簡單的應用。
:
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
: nginx改吧
:
: 改吧 你提这种问题没意思的很
:
索南都不容易啊，大家一起转码拿大包不好吗？
【 在 dracodoc (david) 的大作中提到: 】
: 任何一个功能要做好都没有简单的
: 这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为
: 了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多
: 少钱途，因为nginx已经push到极限了，很难有余地做的更好
: 软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以
: 开始个项目，但那根本不是产品
golang的问题，即使用124个线程，性能也无法达到nginx在48核上98%的占用率，
golang http benchmark只有30%占用率。
https://github.com/golang/benchmarks/blob/master/http/http.go
【 在 echowuhao (echo) 的大作中提到: 】
: 看了一下algernon 一个人搞的大杂烩。
: lz你比较各啥。
【 在 magagop (magagop) 的大作中提到: 】
: 刚刚用了golang official的http benchmark，得到跟algernon同样的结果，说明还是
: golang的问题，即使用124个线程，性能也无法达到nginx在48核上98%的占用率，
: golang http benchmark只有30%占用率。
: https://github.com/golang/benchmarks/blob/master/http/http.go
我现在用这个：https://github.com/golang/benchmarks/blob/master/http/http.go
48核30k RPS，nginx是400k以上
【 在 dapangmao (dapangmao) 的大作中提到: 】
: go本身就有http.FileServer，为什么要用第三方库。
: 性能跟nginx相差不大
: https://www.reddit.com/r/golang/comments/28so0e/go_networking_performance_vs
: _nginx/
是golang需要额外调优，跟jvm一样https://github.com/golang/benchmarks/blob/
master/http/http.go
【 在 StevenTen (你来挖坑，我来填) 的大作中提到: 】
: algernon 性能比nginx慢几十倍，你就得出golang不行了…… 然后感叹硬件不好混...
: .无力吐槽
其实性能比c弱多了，根本就不是类似好么。
【 在 dracodoc (david) 的大作中提到: 】
: 任何一个功能要做好都没有简单的
: 这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为
: 了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多
: 少钱途，因为nginx已经push到极限了，很难有余地做的更好
: 软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以
: 开始个项目，但那根本不是产品
核，NUMA架构，还懂服务器设计的人才实在太少，怎么满足的了人民群众日益增长的需求啊
【 在 magagop (magagop) 的大作中提到: 】
: 我的主要觀點是硬件設計非常謹慎，我們改幾行RTL都得層層審批，一幫大牛評估，可
: 有可無的都被砍掉，於是硬件CPU廠家的性能差距越來越小。而軟件互聯網領域開發要
: 求糙快猛，實現同樣的功能，性能差異極大，導致各種方便麵語言橫行，golang是一個
: ，python更差，java也不咋滴。
: 我認為主要原因不是golang、python、java這些語言爛，而是用這些語言的大部分程序
: 員普遍缺乏軟件效率和CPU架構的基本常識，寫的東西爛。但這些並不妨礙他們的
: package大，福利更好。因為硬件領域狡兔死獵狗烹，做得太穩定就沒工作了。
:
: 你这个引申的结论就不合适了
:
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
: 市场
: ...................
algernon支持的feature一大堆，却连基本的http static file都做不好。
说明很多开源项目的功能其实是只能看看而已，别当真。
golang不吹牛说跟C效率类似，就更没有人用了
【 在 yizhongxunhu (刷题转码 工资翻倍) 的大作中提到: 】
: 其实magagop兄耿耿于怀的就是那帮傻x凭啥挣那么多了，百思不得其解
: 索南都不容易啊，大家一起转码拿大包不好吗？
话说我看到很多benchmark都没有差10倍，C肯定是要快，不过你可以贴code看看是不是哪里测试错了
【 在 magagop (magagop) 的大作中提到: 】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 同学，这些语言的目的就是让人不需要了解硬件底层都可以写，要不又懂CPU，又懂多
: 核，NUMA架构，还懂服务器设计的人才实在太少，怎么满足的了人民群众日益增长的需
: 求啊
就是这个
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 其实你可以去把它那个改好，就也能拿大包裹了：）
: 话说我看到很多benchmark都没有差10倍，C肯定是要快，不过你可以贴code看看是不是
: 哪里测试错了
【 在 magagop (magagop) 的大作中提到: 】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
【 在 magagop (magagop) 的大作中提到: 】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
: 軟件設計太重要了，今天測試golang algernon http server靜態文件性能，比nginx差
: 了幾十倍以上。在我們硬件CPU領域，別說差幾倍，性能提升5%都叫大改進，可以更新
: 一代架構了。
: 這使我對golang寫的多核應用程序性能產生懷疑：一個http server在48核處理器上居
: 然搞出124個threads，而且沒有pin to core，不識別numa，簡單靜態文件性能還沒有
: nginx的零頭多，75% CPU都是idle，有失golang的水準。
: 這讓我想到了EE工程師的悲哀：世界上硬件CPU公司屈指可數，最牛的CPU公司性能比最
: 差的快也不到一倍。而不合格的軟件工程師寫的爛程序糟蹋多核CPU，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
: ...................
【 在 magagop (magagop) 的大作中提到: 】
: NGINX就做得很好啊，给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
: 古怪的新语言：golang/rust/scala等等。
够参与这方面的工作岂不是立马就大包裹了.看问题角度要不同嘛，你看到一个东西烂
，但是还很受欢迎，不要去质疑为什么烂还收欢迎，要去想为啥这么烂还能收欢迎，我稍微改进下岂不是可以日进斗金。这样想大包裹自然来。
随便给两个你看看
https://docs.google.com/document/u/0/d/1d3iI2QWURgDIsSR6G2275vMeQ_X7w-
qxM2Vp7iGwwuM/pub
https://docs.google.com/document/d/1At2Ls5_
fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit
【 在 magagop (magagop) 的大作中提到: 】
: NGINX就做得很好啊，给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
: 古怪的新语言：golang/rust/scala等等。
> : fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit
竟然是Russ Cox，多年前经常在USACO上看到他的题解，往事如梦啊
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 话说老兄觉得Golang现在没法pin to core，不识NUMA，这正是大好机会啊，你要是能
: 够参与这方面的工作岂不是立马就大包裹了.看问题角度要不同嘛，你看到一个东西烂
: ，但是还很受欢迎，不要去质疑为什么烂还收欢迎，要去想为啥这么烂还能收欢迎，我
: 稍微改进下岂不是可以日进斗金。这样想大包裹自然来。
: 随便给两个你看看
: https://docs.google.com/document/u/0/d/1d3iI2QWURgDIsSR6G2275vMeQ_X7w-
: qxM2Vp7iGwwuM/pub
: https://docs.google.com/document/d/1At2Ls5_
: fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit
// scanobject scans the object starting at b, adding pointers to gcw.
// b must point to the beginning of a heap object or an oblet.
// scanobject consults the GC bitmap for the pointer mask and the
// spans for the size of the object.
//
//go:nowritebarrier
func scanobject(b uintptr, gcw *gcWork) {
// Note that arena_used may change concurrently during
// scanobject and hence scanobject may encounter a pointer to
// a newly allocated heap object that is *not* in
// [start,used). It will not mark this object; however, we
// know that it was just installed by a mutator, which means
// that mutator will execute a write barrier and take care of
// marking it. This is even more pronounced on relaxed memory
// architectures since we access arena_used without barriers
// or synchronization, but the same logic applies.
...
// Work here is duplicated in scanblock and above.
// If you make changes here, make changes there too.
obj := *(*uintptr)(unsafe.Pointer(b + i)) ===> this line caused cache miss?
// At this point we have extracted the next potential
pointer.
// Check if it points into heap and not back at the current object.
if obj != 0 && arena_start <= obj && obj < arena_used && obj-b >= n {
// Mark the object.
if obj, hbits, span, objIndex := heapBitsForObject(
obj, b, i); obj != 0 {
greyobject(obj, b, i, hbits, span, gcw,
objIndex)
}
}
【 在 magagop (magagop) 的大作中提到: 】
: 罪魁祸首找到了：obj := *(*uintptr)(unsafe.Pointer(b + i))
: // scanobject scans the object starting at b, adding pointers to gcw.
: // b must point to the beginning of a heap object or an oblet.
: // scanobject consults the GC bitmap for the pointer mask and the
: // spans for the size of the object.
: //
: //go:nowritebarrier
: func scanobject(b uintptr, gcw *gcWork) {
: // Note that arena_used may change concurrently during
: // scanobject and hence scanobject may encounter a pointer to
: ...................
【 在 magagop (magagop) 的大作中提到: 】
: 罪魁祸首找到了：obj := *(*uintptr)(unsafe.Pointer(b + i))
: // scanobject scans the object starting at b, adding pointers to gcw.
: // b must point to the beginning of a heap object or an oblet.
: // scanobject consults the GC bitmap for the pointer mask and the
: // spans for the size of the object.
: //
: //go:nowritebarrier
: func scanobject(b uintptr, gcw *gcWork) {
: // Note that arena_used may change concurrently during
: // scanobject and hence scanobject may encounter a pointer to
: ...................
1. GOGC，关闭Garbage Collection，性能提高20%，无语了，golang不是吹牛GC比JVM G1强很多么？NGINX不用GC不是照样可以写程序么？
2. 滥用FUTEX，从strace上看，一个HTTP GET引发众多threads拼抢，thundering herd problem，跟NGINX的SO_REUSEPORT设计完全不同。GO runtime调度需要用futex，众多goroutines给本来就很脆弱的futex加重负担。
各位大侠，我没学过golang，只花了几天测测http性能，就发现这两个问题，这应该是设计失误吧？
[pid 29063] <... epoll_wait="" resumed=""> [{EPOLLIN|EPOLLOUT, {u32=4228357504,
u64=140170486062464}}], 128, -1) = 1
[pid 29063] futex(0x147c010, FUTEX_WAKE, 1) = 1
[pid 29063] read(6,
[pid 29010] <... futex="" resumed=""> ) = 0
[pid 29063] <... read="" resumed=""> "GET /1kb HTTP/1.1\r\nHost: dx-1"..., 4096) = 1316
[pid 29010] pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=20000}, NULL <
unfinished ...>
[pid 29063] futex(0x1481040, FUTEX_WAKE, 1) = 1
[pid 29977] <... futex="" resumed=""> ) = 0
[pid 29977] futex(0x1481040, FUTEX_WAIT, 0, {tv_sec=0, tv_nsec=994743017} <
unfinished ...>
[pid 29010] <... pselect6="" resumed=""> ) = 0 (Timeout)
[pid 29063] futex(0x1481040, FUTEX_WAKE, 1
[pid 29010] pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=20000}, NULL <
unfinished ...>
[pid 29977] <... futex="" resumed=""> ) = 0
[pid 29063] <... futex="" resumed=""> ) = 1
[pid 29977] sched_yield(
[pid 29063] futex(0xc42434c148, FUTEX_WAKE, 1
[pid 29977] <... sched_yield="" resumed=""> ) = 0
[pid 29063] <... futex="" resumed=""> ) = 1
[pid 29977] futex(0x1481020, FUTEX_WAKE, 1
[pid 29063] futex(0x1481040, FUTEX_WAKE, 1
[pid 29977] <... futex="" resumed=""> ) = 0
[pid 29063] <... futex="" resumed=""> ) = 0
[pid 29977] sched_yield(
[pid 29019] <... futex="" resumed=""> ) = 0
[pid 29977] <... sched_yield="" resumed=""> ) = 0
[pid 29019] epoll_wait(4,
[pid 29977] futex(0x1481020, FUTEX_WAKE, 1
[pid 29019] <... epoll_wait="" resumed=""> [], 128, 0) = 0
[pid 29977] <... futex="" resumed=""> ) = 0
[pid 29063] write(6, "HTTP/1.1 200 OK\r\nAccept-Ranges: "..., 1444 <
unfinished ...>
[pid 29977] futex(0x1481040, FUTEX_WAIT, 0, {tv_sec=9, tv_nsec=999836825} <
unfinished ...>
[pid 29019] futex(0xc432ddc948, FUTEX_WAKE, 1
[pid 29063] <... write="" resumed=""> ) = 1444
[pid 29019] <... futex="" resumed=""> ) = 1
[pid 29063] futex(0x1481040, FUTEX_WAKE, 1
[pid 29010] <... pselect6="" resumed=""> ) = 0 (Timeout)
[pid 29977] <... futex="" resumed=""> ) = 0
[pid 29063] <... futex="" resumed=""> ) = 1
[pid 29977] sched_yield(
[pid 29062] <... futex="" resumed=""> ) = 0
[pid 29977] <... sched_yield="" resumed=""> ) = 0
[pid 29063] read(6,
[pid 29977] futex(0x1481020, FUTEX_WAKE, 1
[pid 29063] <... read="" resumed=""> 0xc42ed24000, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
[pid 29977] <... futex="" resumed=""> ) = 0
[pid 29063] epoll_wait(4,
[pid 29977] futex(0x1481040, FUTEX_WAIT, 0, {tv_sec=9, tv_nsec=999668369} <
unfinished ...>
[pid 29063] <... epoll_wait="" resumed=""> [], 128, 0) = 0
[pid 29062] epoll_wait(4,
[pid 29063] epoll_wait(4,
[pid 29062] <... epoll_wait="" resumed=""> [], 128, 0) = 0
[pid 29019] epoll_wait(4,
[pid 29062] futex(0xc432ddc948, FUTEX_WAIT, 0, NULL
[pid 29019] <... epoll_wait="" resumed=""> [], 128, 0) = 0
[pid 29010] pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=20000}, NULL <
unfinished ...>
[pid 29019] futex(0xc42434c148, FUTEX_WAIT, 0, NULL
[pid 29010] <... pselect6="" resumed=""> ) = 0 (Timeout)
[pid 29010] futex(0x147c010, FUTEX_WAIT, 0, {tv_sec=60, tv_nsec=0} <
unfinished ...>
[pid 29977] <... futex="" resumed=""> ) = -1 ETIMEDOUT (Connection timed out)
[pid 29977] futex(0x147c010, FUTEX_WAKE, 1) = 1
[pid 29977] futex(0x1481040, FUTEX_WAIT, 0, {tv_sec=0, tv_nsec=15876} <
unfinished ...>
[pid 29010] <... futex="" resumed=""> ) = 0
[pid 29010] pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=20000}, NULL <
unfinished ...>
[pid 29977] <... futex="" resumed=""> ) = -1 ETIMEDOUT (Connection timed out)
[pid 29977] futex(0xc42434c148, FUTEX_WAKE, 1) = 1
[pid 29019] <... futex="" resumed=""> ) = 0
[pid 29977] futex(0xc432ddc948, FUTEX_WAKE, 1
[pid 29019] futex(0xc4340ffd48, FUTEX_WAKE, 1
[pid 29977] <... futex="" resumed=""> ) = 1
[pid 29062] <... futex="" resumed=""> ) = 0
[pid 29977] futex(0x1481040, FUTEX_WAIT, 0, {tv_sec=5, tv_nsec=730378996} <
unfinished ...>
[pid 29062] futex(0xc432ddc948, FUTEX_WAIT, 0, NULL
[pid 29508] <... futex="" resumed=""> ) = 0
[pid 29019] <... futex="" resumed=""> ) = 1
[pid 29508] futex(0xc4340ffd48, FUTEX_WAIT, 0, NULL
[pid 29010] <... pselect6="" resumed=""> ) = 0 (Timeout)
[pid 29019] epoll_ctl(4, EPOLL_CTL_DEL, 6, 0xc43657db64) = 0
[pid 29010] pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=20000}, NULL <
unfinished ...>
[pid 29019] close(6) = 0
[pid 29019] futex(0xc4340ffd48, FUTEX_WAKE, 1) = 1
[pid 29010] <... pselect6="" resumed=""> ) = 0 (Timeout)
[pid 29019] futex(0xc42434c148, FUTEX_WAIT, 0, NULL
[pid 29508] <... futex="" resumed=""> ) = 0
[pid 29010] pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=20000}, NULL <
unfinished ...>
[pid 29508] futex(0xc4340ffd48, FUTEX_WAIT, 0, NULL
[pid 29010] <... pselect6="" resumed=""> ) = 0 (Timeout)
[pid 29010] futex(0x147c010, FUTEX_WAIT, 0, {tv_sec=60, tv_nsec=0} <
unfinished ...>
垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实也很高。一般
比20%要大。
当然我可以用空间换时间。但是那是customize allocators。
【 在 magagop (magagop) 的大作中提到: 】
: golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
: 垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
: algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
gc作者之一在这里https://groups.google.com/forum/m/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8
【 在 magagop(magagop) 的大作中提到: 】
<br>: 罪魁祸首找到了：obj := *(*uintptr)(unsafe.Pointer(b i))
<br>: // scanobject scans the object starting at b, adding pointers to gcw.
<br>: // b must point to the beginning of a heap object or an oblet.
<br>: // scanobject consults the GC bitmap for the pointer mask and
the
<br>: // spans for the size of the object.
<br>: //
<br>: //go:nowritebarrier
<br>: func scanobject(b uintptr, gcw *gcWork) {
<br>: // Note that arena_used may change concurrently during
<br>: // scanobject and hence scanobject may encounter a
pointer to
: ...................
<br>
c的话比较复杂，各种编译器各种优化什么的。
【 在 TeacherWei(TW) 的大作中提到: 】
<br>: pid 29010 貌似是GC thread。否则没法解释20us醒一次。
<br>: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实
也很高
。一般
<br>: 比20%要大。
<br>: 当然我可以用空间换时间。但是那是customize allocators。
<br>
两个问题
1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
话说完全可以提交一个PR了
【 在 magagop (magagop) 的大作中提到: 】
: 目前发现两大问题：
: 1. GOGC，关闭Garbage Collection，性能提高20%，无语了，golang不是吹牛GC比
JVM
: G1强很多么？NGINX不用GC不是照样可以写程序么？
: 2. 滥用FUTEX，从strace上看，一个HTTP GET引发众多threads拼抢，thundering
herd
: problem，跟NGINX的SO_REUSEPORT设计完全不同。GO runtime调度需要用futex，众多
: goroutines给本来就很脆弱的futex加重负担。
: 各位大侠，我没学过golang，只花了几天测测http性能，就发现这两个问题，这应该是
: 设计失误吧？
: [pid 29063] <... epoll_wait="" resumed=""> [{EPOLLIN|EPOLLOUT, {u32=4228357504, : u64=140170486062464}}], 128, -1) = 1
: ...................
这个比较对golang不太公平。golang可以做很多事情，nginx专长做web server。
【 在 magagop (magagop) 的大作中提到: 】
: golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
: 垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
: algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
关，看起来象。
2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少futex调用。
我说的不一定对。
【 在 magagop (magagop) 的大作中提到: 】
: 目前发现两大问题：
: 1. GOGC，关闭Garbage Collection，性能提高20%，无语了，golang不是吹牛GC比
JVM
: G1强很多么？NGINX不用GC不是照样可以写程序么？
: 2. 滥用FUTEX，从strace上看，一个HTTP GET引发众多threads拼抢，thundering
herd
: problem，跟NGINX的SO_REUSEPORT设计完全不同。GO runtime调度需要用futex，众多
: goroutines给本来就很脆弱的futex加重负担。
: 各位大侠，我没学过golang，只花了几天测测http性能，就发现这两个问题，这应该是
: 设计失误吧？
: [pid 29063] <... epoll_wait="" resumed=""> [{EPOLLIN|EPOLLOUT, {u32=4228357504, : u64=140170486062464}}], 128, -1) = 1
: ...................
这样来做，不太可能有好的性能啊。:)
【 在 digua (姚之FAN) 的大作中提到: 】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
: JVM
: ...................
以肯定比不过专门针对epoll做的IO密集型nginx？
【 在 digua (姚之FAN) 的大作中提到: 】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
: JVM
: ...................
【 在 digua (姚之FAN) 的大作中提到: 】
: 看了一下algernon源代码，好像就是用了golang的http包，在上面加了一层处理各种文
: 件类型...如果我的理解没错。
: 这样来做，不太可能有好的性能啊。:)
socket accept上的瓶颈。
golang不支持这个我挺吃惊的。NGINX 1.9就有了。对于业务繁重的HTTP服务器，或者
压力测试，SO_REUSEPORT必不可少。
感觉默认的goroutine blocking工作模式效率比non-blocking event poll低很多，虽
然编程更容易。
难道后端不应该都是non-blocking模式么？还有goroutine概念，给硬件加速带来负担
。不知道各种网卡traffic steering技术对golang有没有效果。
【 在 digua (姚之FAN) 的大作中提到: 】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
: JVM
: ...................
好弄，也不好优化。
Cassandra为了躲避GC，特地用JNI搞了offheap objects，malloc也换成jemalloc，这
不就是Cpp么？
JVM GC效率也是问题，G1比CMS慢好多，Shenandoah比G1更慢。。。
关于20%问题，对于软件工程师可能不算什么，对于硬件CPU，10%以上就可以决定跑分
输赢。
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 赞干货
: 两个问题
: 1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
: 定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
: GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
: 2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
: 话说完全可以提交一个PR了
: JVM
: herd
我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
都这么做了
只有亚麻和阿里是奇葩。
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 可预测性很重要。jvm最早时候我记得老死机吧？
: c的话比较复杂，各种编译器各种优化什么的。
:
: pid 29010 貌似是GC thread。否则没法解释20us醒一次。
:
: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实
: 也很高
: 。一般
:
: 比20%要大。
:
: 当然我可以用空间换时间。但是那是customize allocators。
:
顶级人才满足不了人民群众日益增长需求，要精通太难了。
做大规模项目
human is always the least scalable in your system
【 在 magagop (magagop) 的大作中提到: 】
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
: 都这么做了
: 只有亚麻和阿里是奇葩。
【 在 magagop (magagop) 的大作中提到: 】
: SO_REUSEPORT是Linux Kernel 3.9里面新加的，可以让多个process共享socket，减少
: socket accept上的瓶颈。
: golang不支持这个我挺吃惊的。NGINX 1.9就有了。对于业务繁重的HTTP服务器，或者
: 压力测试，SO_REUSEPORT必不可少。
: 感觉默认的goroutine blocking工作模式效率比non-blocking event poll低很多，虽
: 然编程更容易。
: 难道后端不应该都是non-blocking模式么？还有goroutine概念，给硬件加速带来负担
: 。不知道各种网卡traffic steering技术对golang有没有效果。
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 你看看这个？
: https://github.com/kavu/go_reuseport
: https://github.com/libp2p/go-reuseport
去别的node
【在 magagop(magagop)的大作中提到：】
：自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
：我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
大的雞群，層數多，服務複雜，這1%的tail latency將會被放大很多倍，這個blog有討論：http://accelazh.github.io/storage/Tail-Latency-Study
百度GO-BFE應用也討論過這個問題，他們的結論居然跟我昨天上面寫得一樣：
1。關閉GOGC，優化tail latency。
2。目前沒有辦法解決大量goroutine的併發問題，只能拚機器，靠GO研發4倍于C非阻塞事件編程的效率，來彌補goroutine性能問題。
結論是GO可以被使用，但需要優化。
【 在 wwzz (一辈子当码工) 的大作中提到: 】
: 绝大部分的应用对实时性的要求是可以容忍 偶尔 long gc。 一般互联网公司 SLA
99.
: 99% 在 large distributed system 里，别说 long paused GC, 整个机器不见了的事
: 情时刻在发生。客户端容错做好就行了，一个 request timeout, 下一个 request 就
: 去别的node
: ：自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: ：我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度
华为
【 在 magagop (magagop) 的大作中提到: 】
: 其實不是這樣的，這個問題叫long tail latency problem，困擾我們很久了，因為越
: 大的雞群，層數多，服務複雜，這1%的tail latency將會被放大很多倍，這個blog有討
: 論：http://accelazh.github.io/storage/Tail-Latency-Study
: 百度GO-BFE應用也討論過這個問題，他們的結論居然跟我昨天上面寫得一樣：
: 1。關閉GOGC，優化tail latency。
: 2。目前沒有辦法解決大量goroutine的併發問題，只能拚機器，靠GO研發4倍于C非阻塞
: 事件編程的效率，來彌補goroutine性能問題。
: 結論是GO可以被使用，但需要優化。
: https://youtu.be/n9FkJkMdzL4
: 99.
: ...................
现在golang运行环境大部分其实更复杂，很多事在cloud上的VM做的，VM针对bare
linux的调度就是多了一层，如果用container（绝大部分golang都用k8s或者其他
container的部署技术）比如k8s，那么一个VM只是一个node，上面还有很多pod，又加
了一层隔离，其中的网络配置方式也可以有多种。所以这个性能优化还真是一个大课题。搞定这个绝对大包不愁啊
magagop 你底层系统经验这么好，绝对应该搞搞这个
【 在 magagop (magagop) 的大作中提到: 】
: 其實不是這樣的，這個問題叫long tail latency problem，困擾我們很久了，因為越
: 大的雞群，層數多，服務複雜，這1%的tail latency將會被放大很多倍，這個blog有討
: 論：http://accelazh.github.io/storage/Tail-Latency-Study
: 百度GO-BFE應用也討論過這個問題，他們的結論居然跟我昨天上面寫得一樣：
: 1。關閉GOGC，優化tail latency。
: 2。目前沒有辦法解決大量goroutine的併發問題，只能拚機器，靠GO研發4倍于C非阻塞
: 事件編程的效率，來彌補goroutine性能問題。
: 結論是GO可以被使用，但需要優化。
: https://youtu.be/n9FkJkMdzL4
: 99.
: ...................
基本就是线程很多的时候，GC频繁回收大量的临时变量，导致性能提升不大。
他调节了GOGC的参数，最后能够充分利用24核，性能提高23倍。
【 在 magagop(magagop) 的大作中提到: 】
<br>: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
<br>: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软
腾讯百
度华为
<br>: 都这么做了
<br>: 只有亚麻和阿里是奇葩。
<br>
变量会好一些。至少减轻GC的压力。
【 在 magagop(magagop) 的大作中提到: 】
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百
度华为
: 都这么做了
: 只有亚麻和阿里是奇葩。
有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。
【 在 magagop (magagop) 的大作中提到: 】
: 剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
: 有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。
https://docs.google.com/document/u/0/d/1d3iI2QWURgDIsSR6G2275vMeQ_X7w-
qxM2Vp7iGwwuM/pubhttps://groups.google.com/forum/#!topic/golang-dev/Hjj3fPBLXlk
少的。
The main concepts in Go runtime are:
M - OS thread (Machine).
P - Logical CPU (Processor), there are exactly GOMAXPROCS P's.
G - Goroutine.
Netpoll - network poller (epoll descriptor).
RunQ - scheduler queue with runnable G's.
MHeap - global memory allocator state (contains central caches and free
spans).
MCache - per-P memory allocator cache.
GC - garbage collector.
Current system architecture can be depicted as follows:
Runtime does not try hard to ensure any locality, resources like P's and M's are pooled. Runtime is not aware of system topology. MCache is tied to P,
and this provides some locality. But then P is not tied to M, so this *
locality is easily destroyable*. New G's are generally submitted to the
local RunQ, but once again P is not tied to M. When an M returns from a
syscall quickly, it tries to re-acquire the same P it used before the
syscall.
线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
【 在 ycj (ycj) 的大作中提到: 】
: 关于Go的多线程GC慢的问题，这里有一个解释：
: https://blog.cloudflare.com/go-dont-collect-my-garbage/
: 基本就是线程很多的时候，GC频繁回收大量的临时变量，导致性能提升不大。
: 他调节了GOGC的参数，最后能够充分利用24核，性能提高23倍。
:
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
:
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软
: 腾讯百
: 度华为
:
: 都这么做了
:
: 只有亚麻和阿里是奇葩。
: ...................
【 在 magagop(magagop) 的大作中提到: 】
: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且
还能非
: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 赞资料
: 现在golang运行环境大部分其实更复杂，很多事在cloud上的VM做的，VM针对bare
: linux的调度就是多了一层，如果用container（绝大部分golang都用k8s或者其他
: container的部署技术）比如k8s，那么一个VM只是一个node，上面还有很多pod，又加
: 了一层隔离，其中的网络配置方式也可以有多种。所以这个性能优化还真是一个大课题
: 。搞定这个绝对大包不愁啊
: magagop 你底层系统经验这么好，绝对应该搞搞这个
【 在 TeacherWei(TW) 的大作中提到: 】
<br>: 俺一直都说，C#是最好的语言。。。。
<br>
听说.NET开源的只是核心库，不是全部，不知道未来怎样。还有IDE和社区，这也很重
要。
【 在 ycj (ycj) 的大作中提到: 】
: Csharp 也是我的favorite。java和它相比很粗糙，cpp 和它相比又太复杂混乱。
:
: 俺一直都说，C#是最好的语言。。。。
:
【 在 ycj (ycj) 的大作中提到: 】
: 把GC完全关掉，时间一长，非耗尽内存空间不可。
:
: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且
: 还能非
:
: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
:
【 在 magagop(magagop) 的大作中提到: 】
: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。
【 在 ycj (ycj) 的大作中提到: 】
: 我自己瞎猜的，如果内存一点也不释放的话，会损失Cache locality, 内存空间会碎片
: 化。
:
: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。
:
stream好用啊
【 在 magagop (magagop) 的大作中提到: 】
: CSharp在Linux、非x86架构下有性能很好的编译器和库么？
: 听说.NET开源的只是核心库，不是全部，不知道未来怎样。还有IDE和社区，这也很重
: 要。
【 在 digua (姚之FAN) 的大作中提到: 】
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。
【 在 magagop (magagop) 的大作中提到: 】
: 这里面讲了，为什么goroutine太多，在多路众核处理器上会大量造成cache-line
miss
: 和ping-pong效应。我们目前最强的机器是2路200+核心16个内存控制器，还没有测试，
: 估计golang性能因为scheduling会很难看。做处理器的最怕跨路访问内存，一个load应
: 该有200~300ns延时，再加上超标量，相当于等待成百上千条指令啊，性能下降10倍算
: 少的。
: The main concepts in Go runtime are:
: M - OS thread (Machine).
: P - Logical CPU (Processor), there are exactly GOMAXPROCS P's.
: G - Goroutine.
: Netpoll - network poller (epoll descriptor).
: ...................
你目前的实验室基于一个200+核心直接run bare golang的http server？但是实际上很多golang打包container的都是基于pod的，可以试一下k8s，比如你开# of core 个VM
？然后pin每个VM到一个core成为一个node，再每个node上再开2个pod？
所以你原来的测试是1个http server 开N个goroutine，现在变成每个pod上开一个http server，就应该是1个http server开N/200/2个goroutine
这样的scheduler问题就完全变了。不知道效果如何
【 在 magagop (magagop) 的大作中提到: 】
: 这里面讲了，为什么goroutine太多，在多路众核处理器上会大量造成cache-line
miss
: 和ping-pong效应。我们目前最强的机器是2路200+核心16个内存控制器，还没有测试，
: 估计golang性能因为scheduling会很难看。做处理器的最怕跨路访问内存，一个load应
: 该有200~300ns延时，再加上超标量，相当于等待成百上千条指令啊，性能下降10倍算
: 少的。
: The main concepts in Go runtime are:
: M - OS thread (Machine).
: P - Logical CPU (Processor), there are exactly GOMAXPROCS P's.
: G - Goroutine.
: Netpoll - network poller (epoll descriptor).
: ...................
害。
【 在 digua(姚之FAN) 的大作中提到: 】
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。
【 在 silverhawk (silverhawk) 的大作中提到: 】
: page fault不是忙IO把，是swap出去之后重新load进TLB很花时间？
【 在 ycj (ycj) 的大作中提到: 】
: 看那个报告的样子，应该还没有到经常page fault 的地步，否则性能会下降得非常厉
: 害。
:
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache
miss
: 更厉害。
:
繁调度不知道会不会频繁重新load TLB，golang的schedule好像在避免这个
【 在 digua (姚之FAN) 的大作中提到: 】
: 从内存里做TLB refill大约是150-200个纳秒左右吧，page fault的延迟是毫秒级了。
Mono支持Linux的arm64，但性能應該不行（跟gcc 7.2比）
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 用.Net core,比之前那个overhead很高的.net好很多，关键是LINQ比Java 新的那个
: stream好用啊
guest communication in kernel code），而且裡面坑特別多，就不細講了。另外
docker和k8s對非x86的支持也不是很好。
虛擬化和容器不是silverbullet，至少在性能上說。AWS最近就在去VM化，參考AWS
Nitro和baremetal EC2。如果同時用虛擬化和容器，或者雙重虛擬化，性能就別指望了。
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 我觉得你是不是可以换个方法实验
: 你目前的实验室基于一个200+核心直接run bare golang的http server？但是实际上很
: 多golang打包container的都是基于pod的，可以试一下k8s，比如你开# of core 个
VM
: ？然后pin每个VM到一个core成为一个node，再每个node上再开2个pod？
: 所以你原来的测试是1个http server 开N个goroutine，现在变成每个pod上开一个
http
: server，就应该是1个http server开N/200/2个goroutine
: 这样的scheduler问题就完全变了。不知道效果如何
: miss
？关于去VM倒是又是一个课题。
【 在 magagop (magagop) 的大作中提到: 】
: 我們試過lxc和kvm，如果不是Xeon的CPU的話，性能會再下降一個數量級（因為host-: guest communication in kernel code），而且裡面坑特別多，就不細講了。另外
: docker和k8s對非x86的支持也不是很好。
: 虛擬化和容器不是silverbullet，至少在性能上說。AWS最近就在去VM化，參考AWS
: Nitro和baremetal EC2。如果同時用虛擬化和容器，或者雙重虛擬化，性能就別指望了。
: VM
: http
下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
多，這也是亞馬遜買CPU公司做硬件的原因。
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 我的意思是实际上运行环境很多事虚拟化的，你把NGINX跑到VM上是不是也会性能下
降.
: VM肯定性能下降，但是大家（Golang http server 和NGINX）都下降下，你再比较下呢？
: ？关于去VM倒是又是一个课题。
: 了。
intensive的workload，VM和裸机会很接近。
看起来你们用的硬件，对VM中的I/O部分的支持不好啊，不应该影响这么大。有可能是I/O虚拟化的硬件支持不好。感觉你们的系统，要调的地方很多，工作量很大。:)
【 在 magagop (magagop) 的大作中提到: 】
: Nginx下降更多，都用VM結果是nginx和golang的差距比裸機小，從原來的10倍或100倍
: 下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
: 多，這也是亞馬遜買CPU公司做硬件的原因。
但是很少golang是在bare的单机上运行，大部分都是distributed的VM上
【 在 magagop (magagop) 的大作中提到: 】
: Nginx下降更多，都用VM結果是nginx和golang的差距比裸機小，從原來的10倍或100倍
: 下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
: 多，這也是亞馬遜買CPU公司做硬件的原因。
: 降.
: 呢？
VM慢了一个数量级以上，无论如何都不能justify。
被人收割骗钱而已。
【 在 silverhawk (silverhawk) 的大作中提到: 】
: 对啊，我就是这个意思，专门针对单机优化上，最接近底层的C做出来的还是肯定好，
: 但是很少golang是在bare的单机上运行，大部分都是distributed的VM上
【 在 TeacherWei (TW) 的大作中提到: 】
: 其实所谓云架构，大多数是没啥必要的。
: VM慢了一个数量级以上，无论如何都不能justify。
: 被人收割骗钱而已。
monitor，啥都方便，等到服务做大了，再专门自己搞DC做
【 在 TeacherWei (TW) 的大作中提到: 】
: 其实所谓云架构，大多数是没啥必要的。
: VM慢了一个数量级以上，无论如何都不能justify。
: 被人收割骗钱而已。
你不掌握生产资料，所以只能被剥夺剩余价值
卡尔 马克思