logo
Redian新闻
>未名空间
>Programming - 葵花宝典
>
為什麼golang algernon比C nginx慢幾十倍？golang行嗎
avatar
為什麼golang algernon比C nginx慢幾十倍？golang行嗎# Programming - 葵花宝典
h*e
1 楼
现在有个银行愿意把我们checking upgrade成premium，说这样我们贷款的时候可以直
接给0.25%的优惠。但是因为我们以前的checking是在另一个州开的，所以，我们得新
开一个premium，这样的话应该就要查credit score吧。我担心现在新开一个帐号会影
响credit score，如果在这家银行的利率不理想，去其它银行贷款，如果credit score
低了反而不好。我们现在的score应该属于excellent这个档次，具体多少分不知道。
另外，我们现在打算找个realtor，一般要签多长时间的合同，是在此期间，她带我们
看的房子才通过她买，还是我们自己看的房子也要通过她？
新手上路，请多多指教！
avatar
m*p
2 楼
軟件設計太重要了，今天測試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，性能可能下降上
百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
開發部門不停的refactoring，翻修輪子製造工作崗位，才能保證軟件質量和性能。這
樣對於優秀的硬件工程師，跳槽也就一兩家公司競爭offer，而同樣優秀的軟件工程師
會有十幾家或更多公司競爭，包裹大幾倍就成了正常的市場現象。
avatar
w*g
3 楼
软件也是，c的性能被numpy糟蹋，numpy被pandas糟蹋，tensorflow被keras糟蹋，
pandas和keras用的人最多。下里巴人最好找工作。

：軟件設計太重要了，今天測試golang algernon http server靜態文件性能，比nginx
差了幾十倍以上。在我們硬件CPU領域，別說差幾倍，性能提升5%都叫大改進，可以更新
：一代架構了。
avatar
n*p
4 楼
要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者c.
以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞硬件的
功不可没

【在 m*****p 的大作中提到】
: 軟件設計太重要了，今天測試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，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
avatar
g*t
5 楼
Golang写起来和python一样容易。那么
只要比python快几倍就可以了。不和c plus比。
avatar
g*t
6 楼
以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。
现在语言的设计要讨好程序员，不然出门就是死。
在这个程序员民主化进程中，唯一的例外是basic.
Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
不是没有道理的。


: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者
c.

: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞
硬件的

: 功不可没



【在 n***p 的大作中提到】
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者c.
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞硬件的
: 功不可没
avatar
n*p
7 楼
嗯，各花入各眼，很难一个语言一统江湖。

【在 g****t 的大作中提到】
: 以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。
: 现在语言的设计要讨好程序员，不然出门就是死。
: 在这个程序员民主化进程中，唯一的例外是basic.
: Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
: 不是没有道理的。
:
:
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者
: c.
:
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞
: 硬件的
avatar
g*t
8 楼
参考文献
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


: 以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。

: 现在语言的设计要讨好程序员，不然出门就是死。

: 在这个程序员民主化进程中，唯一的例外是basic.

: Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，

: 不是没有道理的。

: c.

: 硬件的



【在 g****t 的大作中提到】
: 以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。
: 现在语言的设计要讨好程序员，不然出门就是死。
: 在这个程序员民主化进程中，唯一的例外是basic.
: Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
: 不是没有道理的。
:
:
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者
: c.
:
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞
: 硬件的
avatar
y*u
9 楼
没用，又没钱，还天天担心被裁，惨惨惨

【在 n***p 的大作中提到】
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者c.
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞硬件的
: 功不可没
avatar
s*y
10 楼
静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是nginx改吧
改吧 你提这种问题没意思的很
avatar
d*c
11 楼
你这个引申的结论就不合适了
搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
多，可能性无限。
硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
件成本算上，而且这个成本是和规模一起放大的。
你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
另外nginx本来就是俄罗斯人搞的，在一个领域追求性能极致，golang是几个人创造工
具创造市场给自己保住饭碗，你用的更不知道是谁写的自己吹牛用的，跟nginx这样在
市场中证明的肯定没法比。

【在 m*****p 的大作中提到】
: 軟件設計太重要了，今天測試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，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
avatar
g*t
12 楼
Can we put go binary server behind the nginx ?

【在 d******c 的大作中提到】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
avatar
m*p
13 楼
就是這種簡單到不行的功能，golang algernon都沒做好，我不是做互聯網的，老闆要
求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個
就像drystone測試，一般都選最簡單的應用。


: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
nginx改吧

: 改吧 你提这种问题没意思的很



【在 s*********y 的大作中提到】
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是nginx改吧
: 改吧 你提这种问题没意思的很
avatar
T*x
14 楼
numpy 糟蹋C的性能了吗？

：软件也是，c的性能被numpy糟蹋，numpy被pandas糟蹋，tensorflow被keras糟蹋，
：pandas和keras用的人最多。下里巴人最好找工作。
avatar
m*p
15 楼
我的主要觀點是硬件設計非常謹慎，我們改幾行RTL都得層層審批，一幫大牛評估，可
有可無的都被砍掉，於是硬件CPU廠家的性能差距越來越小。而軟件互聯網領域開發要
求糙快猛，實現同樣的功能，性能差異極大，導致各種方便麵語言橫行，golang是一個
，python更差，java也不咋滴。
我認為主要原因不是golang、python、java這些語言爛，而是用這些語言的大部分程序
員普遍缺乏軟件效率和CPU架構的基本常識，寫的東西爛。但這些並不妨礙他們的
package大，福利更好。因為硬件領域狡兔死獵狗烹，做得太穩定就沒工作了。


: 你这个引申的结论就不合适了

: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
市场

: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的
事情太

: 多，可能性无限。

: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，
产生新

: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，
成本只

: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得
先把硬

: 件成本算上，而且这个成本是和规模一起放大的。

: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕
你真的

: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。



【在 d******c 的大作中提到】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
avatar
m*p
16 楼
互聯網領域講究一個月上線，勉強完成功能，然後不斷改進提高性能，提升空間有一百
倍以上。硬件正好相反，用幾年時間設計，一旦發布，靠固件和微指令性能提升空間只
有幾個percent，如果出問題（meltdown）新固件性能下降卻很大。這就是我感嘆的地
方。
avatar
n*p
17 楼
试过rust的iron或者rocket没有？ 期待你的评估结果

【在 m*****p 的大作中提到】
: 就是這種簡單到不行的功能，golang algernon都沒做好，我不是做互聯網的，老闆要
: 求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個
: 就像drystone測試，一般都選最簡單的應用。
:
:
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
: nginx改吧
:
: 改吧 你提这种问题没意思的很
:

avatar
w*g
18 楼
可以的，但是该慢还是慢啊。我现在全线从apache2转nginx了。

【在 g****t 的大作中提到】
: Can we put go binary server behind the nginx ?
avatar
m*p
19 楼
你說的scale成本低是不準確的。我們硬件scale有兩種：scale-up和scale-out。你說
的scale成本線性增加是scale-out，但多核處理器設計必須要考慮scale-up，就是在同
樣內存地址空間上爆核心，問題很多，不容易提升。另外MPI算scale-out，OpenMP是
scale-up。互聯網基本是scale-out，傳統數據庫是scale-up。CPU設計兩個都需要考慮。


: 你这个引申的结论就不合适了

: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
市场

: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的
事情太

: 多，可能性无限。

: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，
产生新

: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，
成本只

: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得
先把硬

: 件成本算上，而且这个成本是和规模一起放大的。

: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕
你真的

: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。



【在 d******c 的大作中提到】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
avatar
y*u
20 楼
感觉magagop兄说这么多，还是因为自己挣得太少，如果把你的package和互联网换过来
，你应该很开心吧
加油吧，有空去龟版看看，里面氛转码围很好的
爱你宝贝

【在 m*****p 的大作中提到】
: 互聯網領域講究一個月上線，勉強完成功能，然後不斷改進提高性能，提升空間有一百
: 倍以上。硬件正好相反，用幾年時間設計，一旦發布，靠固件和微指令性能提升空間只
: 有幾個percent，如果出問題（meltdown）新固件性能下降卻很大。這就是我感嘆的地
: 方。
avatar
d*a
21 楼
ngnix快，是因为写它的人对硬件性能非常了解，对软件底层细节抠的很细。连C++都不
用，只用C, 就是为了性能最大化啊。
其实你自己不就是在做这种类型的工作吗？我的理解，你做的工作是系统软件优化，
对吧?

【在 m*****p 的大作中提到】
: 軟件設計太重要了，今天測試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，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
avatar
y*j
22 楼
Apache 的那些project用过几个，每个质量都相当差，印象相对不好。


: 可以的，但是该慢还是慢啊。我现在全线从apache2转nginx了。



【在 w***g 的大作中提到】
: 可以的，但是该慢还是慢啊。我现在全线从apache2转nginx了。
avatar
e*o
23 楼
看了一下algernon 一个人搞的大杂烩。
lz你比较各啥。
avatar
m*u
25 楼
其实这很好理解，什么都是为着客户转的，你看看现在垃圾程序员是大多数，作为语言
的客户，你得为着他们转，搞高了他们弄不转，就不用了，所以没有客户了，语言就挂
了。所以，归根结底，是现在程序员烂货居多导致的。
avatar
S*n
26 楼
algernon 性能比nginx慢几十倍，你就得出golang不行了…… 然后感叹硬件不好混...
.无力吐槽
avatar
d*c
27 楼
任何一个功能要做好都没有简单的
这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为
了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多
少钱途，因为nginx已经push到极限了，很难有余地做的更好
软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以
开始个项目，但那根本不是产品

【在 m*****p 的大作中提到】
: 就是這種簡單到不行的功能，golang algernon都沒做好，我不是做互聯網的，老闆要
: 求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個
: 就像drystone測試，一般都選最簡單的應用。
:
:
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
: nginx改吧
:
: 改吧 你提这种问题没意思的很
:

avatar
y*u
28 楼
其实magagop兄耿耿于怀的就是那帮傻x凭啥挣那么多了，百思不得其解
索南都不容易啊，大家一起转码拿大包不好吗？

【在 d******c 的大作中提到】
: 任何一个功能要做好都没有简单的
: 这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为
: 了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多
: 少钱途，因为nginx已经push到极限了，很难有余地做的更好
: 软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以
: 开始个项目，但那根本不是产品
avatar
m*p
29 楼
刚刚用了golang official的http benchmark，得到跟algernon同样的结果，说明还是
golang的问题，即使用124个线程，性能也无法达到nginx在48核上98%的占用率，
golang http benchmark只有30%占用率。
https://github.com/golang/benchmarks/blob/master/http/http.go

【在 e*******o 的大作中提到】
: 看了一下algernon 一个人搞的大杂烩。
: lz你比较各啥。
avatar
y*u
30 楼
软件做这么烂？为啥还能拿大包呢？百思不得其解啊

【在 m*****p 的大作中提到】
: 刚刚用了golang official的http benchmark，得到跟algernon同样的结果，说明还是
: golang的问题，即使用124个线程，性能也无法达到nginx在48核上98%的占用率，
: golang http benchmark只有30%占用率。
: https://github.com/golang/benchmarks/blob/master/http/http.go
avatar
m*p
32 楼
golang的http microbenchmark结果跟algernon一样，说明不是algernon问题，要不就
是golang需要额外调优，跟jvm一样https://github.com/golang/benchmarks/blob/
master/http/http.go

..

【在 S*******n 的大作中提到】
: algernon 性能比nginx慢几十倍，你就得出golang不行了…… 然后感叹硬件不好混...
: .无力吐槽
avatar
m*p
33 楼
但是http都这么弱，违背了当初golang的卖点：如java一样好用，类似c的性能。
其实性能比c弱多了，根本就不是类似好么。

【在 d******c 的大作中提到】
: 任何一个功能要做好都没有简单的
: 这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为
: 了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多
: 少钱途，因为nginx已经push到极限了，很难有余地做的更好
: 软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以
: 开始个项目，但那根本不是产品
avatar
s*k
34 楼
同学，这些语言的目的就是让人不需要了解硬件底层都可以写，要不又懂CPU，又懂多
核，NUMA架构，还懂服务器设计的人才实在太少，怎么满足的了人民群众日益增长的需
求啊

【在 m*****p 的大作中提到】
: 我的主要觀點是硬件設計非常謹慎，我們改幾行RTL都得層層審批，一幫大牛評估，可
: 有可無的都被砍掉，於是硬件CPU廠家的性能差距越來越小。而軟件互聯網領域開發要
: 求糙快猛，實現同樣的功能，性能差異極大，導致各種方便麵語言橫行，golang是一個
: ，python更差，java也不咋滴。
: 我認為主要原因不是golang、python、java這些語言爛，而是用這些語言的大部分程序
: 員普遍缺乏軟件效率和CPU架構的基本常識，寫的東西爛。但這些並不妨礙他們的
: package大，福利更好。因為硬件領域狡兔死獵狗烹，做得太穩定就沒工作了。
:
:
: 你这个引申的结论就不合适了
:
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
avatar
m*p
35 楼
对头，一个人随便写写，就能开一个项目，拿大包裹。
algernon支持的feature一大堆，却连基本的http static file都做不好。
说明很多开源项目的功能其实是只能看看而已，别当真。
golang不吹牛说跟C效率类似，就更没有人用了

【在 y**********u 的大作中提到】
: 其实magagop兄耿耿于怀的就是那帮傻x凭啥挣那么多了，百思不得其解
: 索南都不容易啊，大家一起转码拿大包不好吗？
avatar
s*k
36 楼
其实你可以去把它那个改好，就也能拿大包裹了：）
话说我看到很多benchmark都没有差10倍，C肯定是要快，不过你可以贴code看看是不是
哪里测试错了

【在 m*****p 的大作中提到】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
avatar
m*p
37 楼
NGINX就做得很好啊，给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
古怪的新语言：golang/rust/scala等等。

【在 s********k 的大作中提到】
: 同学，这些语言的目的就是让人不需要了解硬件底层都可以写，要不又懂CPU，又懂多
: 核，NUMA架构，还懂服务器设计的人才实在太少，怎么满足的了人民群众日益增长的需
: 求啊
avatar
m*p
38 楼
https://github.com/golang/benchmarks/blob/master/http/http.go
就是这个

【在 s********k 的大作中提到】
: 其实你可以去把它那个改好，就也能拿大包裹了：）
: 话说我看到很多benchmark都没有差10倍，C肯定是要快，不过你可以贴code看看是不是
: 哪里测试错了
avatar
y*u
39 楼
赞magagop兄这么坦诚，爱你

【在 m*****p 的大作中提到】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
avatar
y*u
40 楼
赞magagop兄这么坦诚，爱你

【在 m*****p 的大作中提到】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
avatar
h*i
41 楼


【在 m*****p 的大作中提到】
: 軟件設計太重要了，今天測試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，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
avatar
s*k
42 楼
有几个人能有做出Nginx水平啊，广大人民群众的需求这点少的牛人满足不了啊

【在 m*****p 的大作中提到】
: NGINX就做得很好啊，给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
: 古怪的新语言：golang/rust/scala等等。
avatar
s*k
43 楼
话说老兄觉得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

【在 m*****p 的大作中提到】
: NGINX就做得很好啊，给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
: 古怪的新语言：golang/rust/scala等等。
avatar
y*u
44 楼
> : https://docs.google.com/document/d/1At2Ls5_
> : fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit
竟然是Russ Cox，多年前经常在USACO上看到他的题解，往事如梦啊

【在 s********k 的大作中提到】
: 话说老兄觉得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
avatar
m*p
45 楼
罪魁祸首找到了：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
// 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)
}
}
avatar
y*u
46 楼
赞啊，转码浪费了，可是不转还是没钱，唉，人生好难

【在 m*****p 的大作中提到】
: 罪魁祸首找到了：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
avatar
f*t
47 楼
展开说说？

【在 m*****p 的大作中提到】
: 罪魁祸首找到了：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
avatar
m*p
48 楼
目前发现两大问题：
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] <... resumed="" sched_yield=""> ) = 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] <... resumed="" sched_yield=""> ) = 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] <... resumed="" write=""> ) = 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] <... resumed="" sched_yield=""> ) = 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 ...>
avatar
m*p
50 楼
golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
avatar
T*i
51 楼
pid 29010 貌似是GC thread。否则没法解释20us醒一次。
GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实也很高。一般
比20%要大。
当然我可以用空间换时间。但是那是customize allocators。

【在 m*****p 的大作中提到】
: golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
: 垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
: algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
avatar
g*t
52 楼
牛。GC你统计过longest pause什么的吗？
gc作者之一在这里
https://groups.google.com/forum/m/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8


: 罪魁祸首找到了：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



【在 m*****p 的大作中提到】
: golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
: 垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
: algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
avatar
g*t
53 楼
可预测性很重要。jvm最早时候我记得老死机吧？
c的话比较复杂，各种编译器各种优化什么的。


: pid 29010 貌似是GC thread。否则没法解释20us醒一次。

: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实
也很高
。一般

: 比20%要大。

: 当然我可以用空间换时间。但是那是customize allocators。



【在 T********i 的大作中提到】
: pid 29010 貌似是GC thread。否则没法解释20us醒一次。
: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实也很高。一般
: 比20%要大。
: 当然我可以用空间换时间。但是那是customize allocators。
avatar
s*k
54 楼
赞干货
两个问题
1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
话说完全可以提交一个PR了

JVM
herd

【在 m*****p 的大作中提到】
: 目前发现两大问题：
: 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
avatar
d*a
55 楼
如果用golang的syscall包，可以用SO_REUSEPORT吧。OS要支持SO_REUSEPORT。
这个比较对golang不太公平。golang可以做很多事情，nginx专长做web server。

【在 m*****p 的大作中提到】
: golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
: 垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
: algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
avatar
d*a
56 楼
我的两分钱如下： :-)
1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
关，看起来象。
2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
futex调用。
我说的不一定对。

JVM
herd

【在 m*****p 的大作中提到】
: 目前发现两大问题：
: 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
avatar
d*a
57 楼
看了一下algernon源代码，好像就是用了golang的http包，在上面加了一层处理各种文
件类型...如果我的理解没错。
这样来做，不太可能有好的性能啊。:)

【在 d***a 的大作中提到】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
:
avatar
s*k
58 楼
所以说就是golang的这个包并没有做event based loop，还是直接狂开goroutine，所
以肯定比不过专门针对epoll做的IO密集型nginx？

【在 d***a 的大作中提到】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
:
avatar
s*k
59 楼
golfing 里面那个http package最好？

【在 d***a 的大作中提到】
: 看了一下algernon源代码，好像就是用了golang的http包，在上面加了一层处理各种文
: 件类型...如果我的理解没错。
: 这样来做，不太可能有好的性能啊。:)
avatar
m*p
60 楼
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有没有效果。

【在 d***a 的大作中提到】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
:
avatar
m*p
61 楼
内存设计得好，就不需要自动GC。内存泄露可以用工具各种测试，反而JVM GC的bug不
好弄，也不好优化。
Cassandra为了躲避GC，特地用JNI搞了offheap objects，malloc也换成jemalloc，这
不就是Cpp么？
JVM GC效率也是问题，G1比CMS慢好多，Shenandoah比G1更慢。。。
关于20%问题，对于软件工程师可能不算什么，对于硬件CPU，10%以上就可以决定跑分
输赢。

【在 s********k 的大作中提到】
: 赞干货
: 两个问题
: 1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
: 定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
: GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
: 2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
: 话说完全可以提交一个PR了
:
: JVM
: herd
avatar
m*p
62 楼
自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
都这么做了
只有亚麻和阿里是奇葩。

【在 g****t 的大作中提到】
: 可预测性很重要。jvm最早时候我记得老死机吧？
: c的话比较复杂，各种编译器各种优化什么的。
:
:
: pid 29010 貌似是GC thread。否则没法解释20us醒一次。
:
: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实
: 也很高
: 。一般
:
: 比20%要大。
:
: 当然我可以用空间换时间。但是那是customize allocators。
:

avatar
s*k
63 楼
这些大公司里面，CPP，java,golang都用的（当然软软加上C#），CPP是好，但是真是
顶级人才满足不了人民群众日益增长需求，要精通太难了。
做大规模项目
human is always the least scalable in your system

【在 m*****p 的大作中提到】
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
: 都这么做了
: 只有亚麻和阿里是奇葩。
avatar
s*k
64 楼
你看看这个？
https://github.com/kavu/go_reuseport
https://github.com/libp2p/go-reuseport

【在 m*****p 的大作中提到】
: 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有没有效果。
avatar
w*z
66 楼
绝大部分的应用对实时性的要求是可以容忍 偶尔 long gc。 一般互联网公司 SLA 99.
99% 在 large distributed system 里，别说 long paused GC, 整个机器不见了的事
情时刻在发生。客户端容错做好就行了，一个 request timeout, 下一个 request 就
去别的node

：自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
：我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
avatar
m*p
67 楼
其實不是這樣的，這個問題叫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.
华为

【在 w**z 的大作中提到】
: 绝大部分的应用对实时性的要求是可以容忍 偶尔 long gc。 一般互联网公司 SLA 99.
: 99% 在 large distributed system 里，别说 long paused GC, 整个机器不见了的事
: 情时刻在发生。客户端容错做好就行了，一个 request timeout, 下一个 request 就
: 去别的node
:
: ：自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: ：我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
avatar
y*u
68 楼
牛逼，请收下我的膝盖

【在 m*****p 的大作中提到】
: 其實不是這樣的，這個問題叫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
:
avatar
s*k
69 楼
赞资料
现在golang运行环境大部分其实更复杂，很多事在cloud上的VM做的，VM针对bare
linux的调度就是多了一层，如果用container（绝大部分golang都用k8s或者其他
container的部署技术）比如k8s，那么一个VM只是一个node，上面还有很多pod，又加
了一层隔离，其中的网络配置方式也可以有多种。所以这个性能优化还真是一个大课题
。搞定这个绝对大包不愁啊
magagop 你底层系统经验这么好，绝对应该搞搞这个

【在 m*****p 的大作中提到】
: 其實不是這樣的，這個問題叫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
:
avatar
y*j
70 楼
关于Go的多线程GC慢的问题，这里有一个解释：
https://blog.cloudflare.com/go-dont-collect-my-garbage/
基本就是线程很多的时候，GC频繁回收大量的临时变量，导致性能提升不大。
他调节了GOGC的参数，最后能够充分利用24核，性能提高23倍。


: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。

: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软
腾讯百
度华为

: 都这么做了

: 只有亚麻和阿里是奇葩。



【在 m*****p 的大作中提到】
: 其實不是這樣的，這個問題叫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
:
avatar
y*j
71 楼
关于Golang, 我感觉是CPP的一个简化版，但是砍得太猛了，也许留下stack 上的自动
变量会好一些。至少减轻GC的压力。


: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。

: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百
度华为

: 都这么做了

: 只有亚麻和阿里是奇葩。



【在 m*****p 的大作中提到】
: 其實不是這樣的，這個問題叫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
:
avatar
m*p
72 楼
剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。
avatar
T*i
73 楼
俺一直都说，C#是最好的语言。。。。

【在 m*****p 的大作中提到】
: 剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
: 有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。
avatar
m*p
75 楼
这里面讲了，为什么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).
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.
avatar
m*p
76 楼
多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且还能非
线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。

【在 y*j 的大作中提到】
: 关于Go的多线程GC慢的问题，这里有一个解释：
: https://blog.cloudflare.com/go-dont-collect-my-garbage/
: 基本就是线程很多的时候，GC频繁回收大量的临时变量，导致性能提升不大。
: 他调节了GOGC的参数，最后能够充分利用24核，性能提高23倍。
:
:
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
:
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软
: 腾讯百
: 度华为
:
: 都这么做了
avatar
y*j
77 楼
把GC完全关掉，时间一长，非耗尽内存空间不可。


: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且
还能非

: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。



【在 m*****p 的大作中提到】
: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且还能非
: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
avatar
b*s
78 楼
golang + docker may be the best practice

【在 s********k 的大作中提到】
: 赞资料
: 现在golang运行环境大部分其实更复杂，很多事在cloud上的VM做的，VM针对bare
: linux的调度就是多了一层，如果用container（绝大部分golang都用k8s或者其他
: container的部署技术）比如k8s，那么一个VM只是一个node，上面还有很多pod，又加
: 了一层隔离，其中的网络配置方式也可以有多种。所以这个性能优化还真是一个大课题
: 。搞定这个绝对大包不愁啊
: magagop 你底层系统经验这么好，绝对应该搞搞这个
avatar
y*j
79 楼
Csharp 也是我的favorite。java和它相比很粗糙，cpp 和它相比又太复杂混乱。


: 俺一直都说，C#是最好的语言。。。。



【在 T********i 的大作中提到】
: 俺一直都说，C#是最好的语言。。。。
avatar
m*p
80 楼
CSharp在Linux、非x86架构下有性能很好的编译器和库么？
听说.NET开源的只是核心库，不是全部，不知道未来怎样。还有IDE和社区，这也很重
要。

【在 y*j 的大作中提到】
: Csharp 也是我的favorite。java和它相比很粗糙，cpp 和它相比又太复杂混乱。
:
:
: 俺一直都说，C#是最好的语言。。。。
:

avatar
m*p
81 楼
关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。

【在 y*j 的大作中提到】
: 把GC完全关掉，时间一长，非耗尽内存空间不可。
:
:
: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且
: 还能非
:
: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
:

avatar
y*j
82 楼
我自己瞎猜的，如果内存一点也不释放的话，会损失Cache locality, 内存空间会碎片
化。


: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。



【在 m*****p 的大作中提到】
: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。
avatar
d*a
83 楼
内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。

【在 y*j 的大作中提到】
: 我自己瞎猜的，如果内存一点也不释放的话，会损失Cache locality, 内存空间会碎片
: 化。
:
:
: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。
:

avatar
s*k
84 楼
用.Net core,比之前那个overhead很高的.net好很多，关键是LINQ比Java 新的那个
stream好用啊

【在 m*****p 的大作中提到】
: CSharp在Linux、非x86架构下有性能很好的编译器和库么？
: 听说.NET开源的只是核心库，不是全部，不知道未来怎样。还有IDE和社区，这也很重
: 要。
avatar
s*k
85 楼
page fault不是忙IO把，是swap出去之后重新load进TLB很花时间？

害。

【在 d***a 的大作中提到】
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。
avatar
s*k
86 楼
如果本来就是在VM上面再加pod上运行container，这个NUMA的作用还会很大吗？因为没
法控制底层的OS，golang也很难做好scheduler把？

miss

【在 m*****p 的大作中提到】
: 这里面讲了，为什么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).
avatar
s*k
87 楼
我觉得你是不是可以换个方法实验
你目前的实验室基于一个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

【在 m*****p 的大作中提到】
: 这里面讲了，为什么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).
avatar
y*j
88 楼
看那个报告的样子，应该还没有到经常page fault 的地步，否则性能会下降得非常厉
害。


: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss
更厉害。



【在 d***a 的大作中提到】
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。
avatar
d*a
89 楼
从内存里做TLB refill大约是150-200个纳秒左右吧，page fault的延迟是毫秒级了。

【在 s********k 的大作中提到】
: page fault不是忙IO把，是swap出去之后重新load进TLB很花时间？
:
: 害。
avatar
d*a
90 楼
是的，不过如果把GC关掉长时间运行下去，page fault会增加的。

miss

【在 y*j 的大作中提到】
: 看那个报告的样子，应该还没有到经常page fault 的地步，否则性能会下降得非常厉
: 害。
:
:
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss
: 更厉害。
:

avatar
s*k
91 楼
哦所以你意思是swap到disk上了？不做GC确实有可能，不过如果GC下多个goroutine频
繁调度不知道会不会频繁重新load TLB，golang的schedule好像在避免这个

【在 d***a 的大作中提到】
: 从内存里做TLB refill大约是150-200个纳秒左右吧，page fault的延迟是毫秒级了。
avatar
m*p
92 楼
.NET Core 2目前只支持Windows下的arm64，等Linux下也有arm64再開始轉吧。
Mono支持Linux的arm64，但性能應該不行（跟gcc 7.2比）

【在 s********k 的大作中提到】
: 用.Net core,比之前那个overhead很高的.net好很多，关键是LINQ比Java 新的那个
: stream好用啊
avatar
m*p
93 楼
我們試過lxc和kvm，如果不是Xeon的CPU的話，性能會再下降一個數量級（因為host-
guest communication in kernel code），而且裡面坑特別多，就不細講了。另外
docker和k8s對非x86的支持也不是很好。
虛擬化和容器不是silverbullet，至少在性能上說。AWS最近就在去VM化，參考AWS
Nitro和baremetal EC2。如果同時用虛擬化和容器，或者雙重虛擬化，性能就別指望了。

VM
http

【在 s********k 的大作中提到】
: 我觉得你是不是可以换个方法实验
: 你目前的实验室基于一个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
avatar
s*k
94 楼
我的意思是实际上运行环境很多事虚拟化的，你把NGINX跑到VM上是不是也会性能下降.
VM肯定性能下降，但是大家（Golang http server 和NGINX）都下降下，你再比较下呢？
？关于去VM倒是又是一个课题。

了。

【在 m*****p 的大作中提到】
: 我們試過lxc和kvm，如果不是Xeon的CPU的話，性能會再下降一個數量級（因為host-
: guest communication in kernel code），而且裡面坑特別多，就不細講了。另外
: docker和k8s對非x86的支持也不是很好。
: 虛擬化和容器不是silverbullet，至少在性能上說。AWS最近就在去VM化，參考AWS
: Nitro和baremetal EC2。如果同時用虛擬化和容器，或者雙重虛擬化，性能就別指望了。
:
: VM
: http
avatar
m*p
95 楼
Nginx下降更多，都用VM結果是nginx和golang的差距比裸機小，從原來的10倍或100倍
下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
多，這也是亞馬遜買CPU公司做硬件的原因。

降.
呢？

【在 s********k 的大作中提到】
: 我的意思是实际上运行环境很多事虚拟化的，你把NGINX跑到VM上是不是也会性能下降.
: VM肯定性能下降，但是大家（Golang http server 和NGINX）都下降下，你再比较下呢？
: ？关于去VM倒是又是一个课题。
:
: 了。
avatar
d*a
96 楼
你用的nginx和golang algernon是I/O intensive的workload。如果跑compute
intensive的workload，VM和裸机会很接近。
看起来你们用的硬件，对VM中的I/O部分的支持不好啊，不应该影响这么大。有可能是I
/O虚拟化的硬件支持不好。感觉你们的系统，要调的地方很多，工作量很大。:)

【在 m*****p 的大作中提到】
: Nginx下降更多，都用VM結果是nginx和golang的差距比裸機小，從原來的10倍或100倍
: 下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
: 多，這也是亞馬遜買CPU公司做硬件的原因。
:
: 降.
: 呢？
avatar
s*k
97 楼
对啊，我就是这个意思，专门针对单机优化上，最接近底层的C做出来的还是肯定好，
但是很少golang是在bare的单机上运行，大部分都是distributed的VM上

【在 m*****p 的大作中提到】
: Nginx下降更多，都用VM結果是nginx和golang的差距比裸機小，從原來的10倍或100倍
: 下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
: 多，這也是亞馬遜買CPU公司做硬件的原因。
:
: 降.
: 呢？
avatar
T*i
98 楼
其实所谓云架构，大多数是没啥必要的。
VM慢了一个数量级以上，无论如何都不能justify。
被人收割骗钱而已。

【在 s********k 的大作中提到】
: 对啊，我就是这个意思，专门针对单机优化上，最接近底层的C做出来的还是肯定好，
: 但是很少golang是在bare的单机上运行，大部分都是distributed的VM上
avatar
p*u
99 楼
云本来就是为了节省IT support的costs，不是提高性能。

【在 T********i 的大作中提到】
: 其实所谓云架构，大多数是没啥必要的。
: VM慢了一个数量级以上，无论如何都不能justify。
: 被人收割骗钱而已。
avatar
s*k
100 楼
追求性能肯定要自己做，但是大部分应用上云架构主要是方便，开启服务，scale，
monitor，啥都方便，等到服务做大了，再专门自己搞DC做

【在 T********i 的大作中提到】
: 其实所谓云架构，大多数是没啥必要的。
: VM慢了一个数量级以上，无论如何都不能justify。
: 被人收割骗钱而已。
avatar
m*n
101 楼
你和软件工程师只有一个本质差别：
你不掌握生产资料，所以只能被剥夺剩余价值
卡尔 马克思
avatar
j*h
102 楼
不明白。软件工程师不是也在被剥夺剩余价值？
本来软件既是生产资料又是劳动产出，结果给来了个开源。
唉唉唉

【在 m*****n 的大作中提到】
: 你和软件工程师只有一个本质差别：
: 你不掌握生产资料，所以只能被剥夺剩余价值
: 卡尔 马克思
avatar
N*r
103 楼

你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司

【在 j*******h 的大作中提到】
: 不明白。软件工程师不是也在被剥夺剩余价值？
: 本来软件既是生产资料又是劳动产出，结果给来了个开源。
: 唉唉唉
avatar
j*h
104 楼
nginx

【在 N*****r 的大作中提到】
:
: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司
avatar
f*2
105 楼
开源是牛逼但不被承认的社会底层的唯一出路，类似十月革命掀桌子


: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司



【在 N*****r 的大作中提到】
:
: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司
avatar
f*t
106 楼
啥出路？做高质量开源能挣大钱？

【在 f******2 的大作中提到】
: 开源是牛逼但不被承认的社会底层的唯一出路，类似十月革命掀桌子
:
:
: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司
:

avatar
m*n
107 楼
R就是这么搞的
一边开源
一边弄个收费高级版
还有Qt系列也是如此

【在 f*******t 的大作中提到】
: 啥出路？做高质量开源能挣大钱？
avatar
b*t
108 楼
algernon三年四百多个星的野鸡库也敢用
想用go webserver， 试试caddy
avatar
l*p
109 楼
速度不是唯一的要求

【在 T********i 的大作中提到】
: 其实所谓云架构，大多数是没啥必要的。
: VM慢了一个数量级以上，无论如何都不能justify。
: 被人收割骗钱而已。
avatar
m*p
110 楼
IO虛擬化目前只有intel的vt-d、sr-iov、apic-v做得很好，其他非x86架構都不行，因
為軟件問題。別看白皮書介紹得簡單，裡面非常複雜，非常不好做，坑特別多。性能只
有xeon可以接近裸機，這就是xeon佔領99.9%市場的原因，amd都不行。

是I

【在 d***a 的大作中提到】
: 你用的nginx和golang algernon是I/O intensive的workload。如果跑compute
: intensive的workload，VM和裸机会很接近。
: 看起来你们用的硬件，对VM中的I/O部分的支持不好啊，不应该影响这么大。有可能是I
: /O虚拟化的硬件支持不好。感觉你们的系统，要调的地方很多，工作量很大。:)
avatar
w*z
111 楼
现在有自己DC的公司已经没几个了。以后也不太会有新的公司用自己DC了

【在 s********k 的大作中提到】
: 追求性能肯定要自己做，但是大部分应用上云架构主要是方便，开启服务，scale，
: monitor，啥都方便，等到服务做大了，再专门自己搞DC做
avatar
s*k
112 楼
做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在cloud
上，比如netflix，但是99%公司还没到追求极致性能就死掉了

【在 w**z 的大作中提到】
: 现在有自己DC的公司已经没几个了。以后也不太会有新的公司用自己DC了
avatar
w*z
113 楼
你提到的那些都是在 cloud 流行之前开始的，不存在从 cloud 转到 自己 DC 的。公
司规模越大，要转的代价就越大， 真不如乖乖给 aws 写支票。新的有一定规模的公司
，除了 uber, 都在云上。

：做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在
cloud
：上，比如netflix，但是99%公司还没到追求极致性能就死掉了
avatar
f*t
114 楼
Dropbox转到自己的DC了

【在 w**z 的大作中提到】
: 你提到的那些都是在 cloud 流行之前开始的，不存在从 cloud 转到 自己 DC 的。公
: 司规模越大，要转的代价就越大， 真不如乖乖给 aws 写支票。新的有一定规模的公司
: ，除了 uber, 都在云上。
:
: ：做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在
: cloud
: ：上，比如netflix，但是99%公司还没到追求极致性能就死掉了
avatar
w*z
115 楼
that was a bold move.
During its early years, Dropbox ran its entire operation on Amazon’s cloud
computing service. But more recently it has moved much of its
infrastructure off AWS to cut down on costs. The company said that in 2016,
it was able to shrink its cost of revenue by $35.1 million as part of its
AWS migration, which it refers to as “Infrastructure Optimization.” As
tech publication GeekWire notes, the data center move help saved
Dropbox about $75 million over a two-year period.

：Dropbox转到自己的DC了
：
avatar
m*p
116 楼
感覺golang的默認goroutine設計模式有問題，下面是golang http microbenchmark的
perf report：
60.24% [kernel] [k] arch_cpu_idle
6.43% [kernel] [k] _raw_spin_lock
4.40% http [.] runtime.runqgrab
2.19% http [.] runtime.findrunnable
感覺golang如果有很多goroutine和thread，大部分時間都會用在runtime.runqgrab上
，然後runtime.futex會過載，導致系統60% CPU都是idle
avatar
m*p
117 楼
在runtime/proc.go裡面有很多lock(&sched.lock)，
例如把goroutine放到global runq裡面就需要lock
func goschedImpl(gp *g) {
status := readgstatus(gp)
if status&^_Gscan != _Grunning {
dumpgstatus(gp)
throw("bad g status")
}
casgstatus(gp, _Grunning, _Grunnable)
dropg()
lock(&sched.lock)
globrunqput(gp)
unlock(&sched.lock)
schedule()
}
sched是runtime2.go裡面的一個全局變量
var (
allglen uintptr
allm *m
allp []*p // len(allp) == gomaxprocs; may change at safe
points, otherwise immutable
allpLock mutex // Protects P-less reads of allp and all writes
gomaxprocs int32
ncpu int32
forcegc forcegcstate
sched schedt
newprocs int32
)
schedt是一個type struct
type schedt struct {
// accessed atomically. keep at top to ensure alignment on 32-bit
systems.
goidgen uint64
lastpoll uint64
lock mutex
// Global runnable queue.
runqhead guintptr
runqtail guintptr
runqsize int32
// Global cache of dead G's.
gflock mutex
// Central cache of sudog structs.
sudoglock mutex
// Central pool of available defer structs of different sizes.
deferlock mutex
}
lock mutex就是32位變量
// Mutual exclusion locks. In the uncontended case,
// as fast as spin locks (just a few user-level instructions),
// but on the contention path they sleep in the kernel.
// A zeroed Mutex is unlocked (no need to initialize each lock).
type mutex struct {
// Futex-based impl treats it as uint32 key,
// while sema-based impl as M* waitm.
// Used to be a union, but unions break precise GC.
key uintptr
}
func lock實現極其簡單，就是先CAS看鎖了沒，然後spinning一會兒，最後futexsleep：
// This implementation depends on OS-specific implementations of
//
// futexsleep(addr *uint32, val uint32, ns int64)
// Atomically,
// if *addr == val { sleep }
// Might be woken up spuriously; that's allowed.
// Don't sleep longer than ns; ns < 0 means forever.
//
// futexwakeup(addr *uint32, cnt uint32)
// If any procs are sleeping on addr, wake up at most cnt.
func lock(l *mutex) {
// Speculative grab for lock.
v := atomic.Xchg(key32(&l.key), mutex_locked)
if v == mutex_unlocked {
return
}
if ncpu > 1 {
spin = active_spin
}
for {
// Try for lock, spinning. procyield(active_spin_cnt)
// Try for lock, rescheduling. osyield()
// Sleep.
v = atomic.Xchg(key32(&l.key), mutex_sleeping)
if v == mutex_unlocked {
return
}
wait = mutex_sleeping
futexsleep(key32(&l.key), mutex_sleeping, -1)
}
}
avatar
m*p
118 楼
所以我前面提到的golang性能的第二個問題不是algernon獨有，也是golang區別於c的
最大特點：goroutine。目前golang最多能有一千萬併發goroutines，換成內存也就是
幾十GB，對於AWS上的只有幾十GB的VM小系統估計夠用了，但是對於多路1TB共享內存大
系統，golang目前沒有NUMA調度架構顯然不行。
測試golang http，其實變成了測試Linux sys_futex()，唉。。。
avatar
c*f
119 楼
现在只有很极致的公司才追求那10%的性能优化 更多的追求实用 短平快
人家根本不care这点区别 再堆机器就是了 机器多少钱 我请人回来弄类似nginx的
memory trick得花多少钱 以后怎么维护？ 升级 更新怎么办？
就想之前碰到一个公司 所有的http服务都是in house的 结果碰到H2 自己做的基于LVS
的链接toss back不能用了不说 连H2的功能的prototype都要做好久
但是市场需求就是马上要H2 你怎么办？ 只能去掉自己in house的LB
所有在用人成本 今后维护 各方面来说 真的可以追求那最顶点性能优化的公司也就没
几个
现在K8S这么热 大家都网上迁呢 谁在乎调度器和API被干爆了如何 多加几个就是了
avatar
m*p
120 楼
看清我的結論：性能差別10倍不止，不是10%，如果是50%，我都會說golang很好。但是
差距1000%，我就呵呵了。

LVS

【在 c****f 的大作中提到】
: 现在只有很极致的公司才追求那10%的性能优化 更多的追求实用 短平快
: 人家根本不care这点区别 再堆机器就是了 机器多少钱 我请人回来弄类似nginx的
: memory trick得花多少钱 以后怎么维护？ 升级 更新怎么办？
: 就想之前碰到一个公司 所有的http服务都是in house的 结果碰到H2 自己做的基于LVS
: 的链接toss back不能用了不说 连H2的功能的prototype都要做好久
: 但是市场需求就是马上要H2 你怎么办？ 只能去掉自己in house的LB
: 所有在用人成本 今后维护 各方面来说 真的可以追求那最顶点性能优化的公司也就没
: 几个
: 现在K8S这么热 大家都网上迁呢 谁在乎调度器和API被干爆了如何 多加几个就是了
avatar
f*t
121 楼
别钻牛角尖了，找到一个特殊的应用说性能差10倍以上，作为技术研究是好的，但没有
实际意义。用Go写backend service的公司很多，碰到性能瓶颈，总会有fix或者
workaround。如果真的需要10倍性能，而Go无论如何都达不到的，就换更合适的语言写
对应的模块唄。

【在 m*****p 的大作中提到】
: 看清我的結論：性能差別10倍不止，不是10%，如果是50%，我都會說golang很好。但是
: 差距1000%，我就呵呵了。
:
: LVS
avatar
m*p
122 楼
http的goroutine和gogc不是特殊應用，是golang做web後台的基礎好麼，回去先看看什
麼是goroutine和gogc再來回復。這兩個問題非常不好workaround，是golang區別於cpp
語言的根子。

【在 f*******t 的大作中提到】
: 别钻牛角尖了，找到一个特殊的应用说性能差10倍以上，作为技术研究是好的，但没有
: 实际意义。用Go写backend service的公司很多，碰到性能瓶颈，总会有fix或者
: workaround。如果真的需要10倍性能，而Go无论如何都达不到的，就换更合适的语言写
: 对应的模块唄。
avatar
g*t
123 楼
做web后台那你就和java比啊。和cpp较劲为哪般呢。。。
任何语言和c／cpp，fortran，pascal比性能都没什么意义。

cpp

【在 m*****p 的大作中提到】
: http的goroutine和gogc不是特殊應用，是golang做web後台的基礎好麼，回去先看看什
: 麼是goroutine和gogc再來回復。這兩個問題非常不好workaround，是golang區別於cpp
: 語言的根子。
avatar
m*p
124 楼
軟件設計太重要了，今天測試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，性能可能下降上
百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
開發部門不停的refactoring，翻修輪子製造工作崗位，才能保證軟件質量和性能。這
樣對於優秀的硬件工程師，跳槽也就一兩家公司競爭offer，而同樣優秀的軟件工程師
會有十幾家或更多公司競爭，包裹大幾倍就成了正常的市場現象。
avatar
w*g
125 楼
软件也是，c的性能被numpy糟蹋，numpy被pandas糟蹋，tensorflow被keras糟蹋，
pandas和keras用的人最多。下里巴人最好找工作。

：軟件設計太重要了，今天測試golang algernon http server靜態文件性能，比nginx
差了幾十倍以上。在我們硬件CPU領域，別說差幾倍，性能提升5%都叫大改進，可以更新
：一代架構了。
avatar
n*p
126 楼
要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者c.
以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞硬件的
功不可没

【在 m*****p 的大作中提到】
: 軟件設計太重要了，今天測試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，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
avatar
g*t
127 楼
Golang写起来和python一样容易。那么
只要比python快几倍就可以了。不和c plus比。
avatar
g*t
128 楼
以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。
现在语言的设计要讨好程序员，不然出门就是死。
在这个程序员民主化进程中，唯一的例外是basic.
Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
不是没有道理的。


: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者
c.

: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞
硬件的

: 功不可没



【在 n***p 的大作中提到】
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者c.
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞硬件的
: 功不可没
avatar
n*p
129 楼
嗯，各花入各眼，很难一个语言一统江湖。

【在 g****t 的大作中提到】
: 以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。
: 现在语言的设计要讨好程序员，不然出门就是死。
: 在这个程序员民主化进程中，唯一的例外是basic.
: Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
: 不是没有道理的。
:
:
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者
: c.
:
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞
: 硬件的
avatar
g*t
130 楼
参考文献
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


: 以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。

: 现在语言的设计要讨好程序员，不然出门就是死。

: 在这个程序员民主化进程中，唯一的例外是basic.

: Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，

: 不是没有道理的。

: c.

: 硬件的



【在 g****t 的大作中提到】
: 以前程序员是硬件的奴隶。然后程序语言是C设计者的奴隶。
: 现在语言的设计要讨好程序员，不然出门就是死。
: 在这个程序员民主化进程中，唯一的例外是basic.
: Basic一开始就要讨好程序员。所以bill gates是basic的粉丝，
: 不是没有道理的。
:
:
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者
: c.
:
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞
: 硬件的
avatar
y*u
131 楼
没用，又没钱，还天天担心被裁，惨惨惨

【在 n***p 的大作中提到】
: 要不是因为EE工程师们的不断努力提升硬件速度，现在最流行的应该是汇编或者c.
: 以前编程要讲究效率，现在“快”的要求从运算速度转向成develop和维护，搞硬件的
: 功不可没
avatar
s*y
132 楼
静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是nginx改吧
改吧 你提这种问题没意思的很
avatar
d*c
133 楼
你这个引申的结论就不合适了
搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
多，可能性无限。
硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
件成本算上，而且这个成本是和规模一起放大的。
你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
另外nginx本来就是俄罗斯人搞的，在一个领域追求性能极致，golang是几个人创造工
具创造市场给自己保住饭碗，你用的更不知道是谁写的自己吹牛用的，跟nginx这样在
市场中证明的肯定没法比。

【在 m*****p 的大作中提到】
: 軟件設計太重要了，今天測試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，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
avatar
g*t
134 楼
Can we put go binary server behind the nginx ?

【在 d******c 的大作中提到】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
avatar
m*p
135 楼
就是這種簡單到不行的功能，golang algernon都沒做好，我不是做互聯網的，老闆要
求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個
就像drystone測試，一般都選最簡單的應用。


: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
nginx改吧

: 改吧 你提这种问题没意思的很



【在 s*********y 的大作中提到】
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是nginx改吧
: 改吧 你提这种问题没意思的很
avatar
T*x
136 楼
numpy 糟蹋C的性能了吗？

：软件也是，c的性能被numpy糟蹋，numpy被pandas糟蹋，tensorflow被keras糟蹋，
：pandas和keras用的人最多。下里巴人最好找工作。
avatar
m*p
137 楼
我的主要觀點是硬件設計非常謹慎，我們改幾行RTL都得層層審批，一幫大牛評估，可
有可無的都被砍掉，於是硬件CPU廠家的性能差距越來越小。而軟件互聯網領域開發要
求糙快猛，實現同樣的功能，性能差異極大，導致各種方便麵語言橫行，golang是一個
，python更差，java也不咋滴。
我認為主要原因不是golang、python、java這些語言爛，而是用這些語言的大部分程序
員普遍缺乏軟件效率和CPU架構的基本常識，寫的東西爛。但這些並不妨礙他們的
package大，福利更好。因為硬件領域狡兔死獵狗烹，做得太穩定就沒工作了。


: 你这个引申的结论就不合适了

: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
市场

: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的
事情太

: 多，可能性无限。

: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，
产生新

: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，
成本只

: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得
先把硬

: 件成本算上，而且这个成本是和规模一起放大的。

: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕
你真的

: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。



【在 d******c 的大作中提到】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
avatar
m*p
138 楼
互聯網領域講究一個月上線，勉強完成功能，然後不斷改進提高性能，提升空間有一百
倍以上。硬件正好相反，用幾年時間設計，一旦發布，靠固件和微指令性能提升空間只
有幾個percent，如果出問題（meltdown）新固件性能下降卻很大。這就是我感嘆的地
方。
avatar
n*p
139 楼
试过rust的iron或者rocket没有？ 期待你的评估结果

【在 m*****p 的大作中提到】
: 就是這種簡單到不行的功能，golang algernon都沒做好，我不是做互聯網的，老闆要
: 求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個
: 就像drystone測試，一般都選最簡單的應用。
:
:
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
: nginx改吧
:
: 改吧 你提这种问题没意思的很
:

avatar
w*g
140 楼
可以的，但是该慢还是慢啊。我现在全线从apache2转nginx了。

【在 g****t 的大作中提到】
: Can we put go binary server behind the nginx ?
avatar
m*p
141 楼
你說的scale成本低是不準確的。我們硬件scale有兩種：scale-up和scale-out。你說
的scale成本線性增加是scale-out，但多核處理器設計必須要考慮scale-up，就是在同
樣內存地址空間上爆核心，問題很多，不容易提升。另外MPI算scale-out，OpenMP是
scale-up。互聯網基本是scale-out，傳統數據庫是scale-up。CPU設計兩個都需要考慮。


: 你这个引申的结论就不合适了

: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
市场

: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的
事情太

: 多，可能性无限。

: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，
产生新

: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，
成本只

: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得
先把硬

: 件成本算上，而且这个成本是和规模一起放大的。

: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕
你真的

: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。



【在 d******c 的大作中提到】
: 你这个引申的结论就不合适了
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造市场
: 但是对软件工程师的需求不是来自于这些被创造的市场，而是来源于软件能做的事情太
: 多，可能性无限。
: 硬件也可以做很多，但做个新硬件的成本和限制太多，周期太长，开辟新市场，产生新
: 产值这方面和软件没法比。软件从开源的开始往加东西，现成的都不需要成本，成本只
: 有很少的硬件成本，scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
: 件成本算上，而且这个成本是和规模一起放大的。
: 你要想转CS，就得学习CS的优点，不能只从酸葡萄心理出发，那没有好处。哪怕你真的
: 认为软件就是靠烂创造市场，那你就该想想你怎么学这一招，也来靠烂创造市场。
avatar
y*u
142 楼
感觉magagop兄说这么多，还是因为自己挣得太少，如果把你的package和互联网换过来
，你应该很开心吧
加油吧，有空去龟版看看，里面氛转码围很好的
爱你宝贝

【在 m*****p 的大作中提到】
: 互聯網領域講究一個月上線，勉強完成功能，然後不斷改進提高性能，提升空間有一百
: 倍以上。硬件正好相反，用幾年時間設計，一旦發布，靠固件和微指令性能提升空間只
: 有幾個percent，如果出問題（meltdown）新固件性能下降卻很大。這就是我感嘆的地
: 方。
avatar
d*a
143 楼
ngnix快，是因为写它的人对硬件性能非常了解，对软件底层细节抠的很细。连C++都不
用，只用C, 就是为了性能最大化啊。
其实你自己不就是在做这种类型的工作吗？我的理解，你做的工作是系统软件优化，
对吧?

【在 m*****p 的大作中提到】
: 軟件設計太重要了，今天測試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，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
avatar
y*j
144 楼
Apache 的那些project用过几个，每个质量都相当差，印象相对不好。


: 可以的，但是该慢还是慢啊。我现在全线从apache2转nginx了。



【在 w***g 的大作中提到】
: 可以的，但是该慢还是慢啊。我现在全线从apache2转nginx了。
avatar
e*o
145 楼
看了一下algernon 一个人搞的大杂烩。
lz你比较各啥。
avatar
m*u
147 楼
其实这很好理解，什么都是为着客户转的，你看看现在垃圾程序员是大多数，作为语言
的客户，你得为着他们转，搞高了他们弄不转，就不用了，所以没有客户了，语言就挂
了。所以，归根结底，是现在程序员烂货居多导致的。
avatar
S*n
148 楼
algernon 性能比nginx慢几十倍，你就得出golang不行了…… 然后感叹硬件不好混...
.无力吐槽
avatar
d*c
149 楼
任何一个功能要做好都没有简单的
这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为
了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多
少钱途，因为nginx已经push到极限了，很难有余地做的更好
软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以
开始个项目，但那根本不是产品

【在 m*****p 的大作中提到】
: 就是這種簡單到不行的功能，golang algernon都沒做好，我不是做互聯網的，老闆要
: 求用各種語言給CPU做benchmark，在golang上就選了algernon，結果性能弱爆了。這個
: 就像drystone測試，一般都選最簡單的應用。
:
:
: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
: nginx改吧
:
: 改吧 你提这种问题没意思的很
:

avatar
y*u
150 楼
其实magagop兄耿耿于怀的就是那帮傻x凭啥挣那么多了，百思不得其解
索南都不容易啊，大家一起转码拿大包不好吗？

【在 d******c 的大作中提到】
: 任何一个功能要做好都没有简单的
: 这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为
: 了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多
: 少钱途，因为nginx已经push到极限了，很难有余地做的更好
: 软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以
: 开始个项目，但那根本不是产品
avatar
m*p
151 楼
刚刚用了golang official的http benchmark，得到跟algernon同样的结果，说明还是
golang的问题，即使用124个线程，性能也无法达到nginx在48核上98%的占用率，
golang http benchmark只有30%占用率。
https://github.com/golang/benchmarks/blob/master/http/http.go

【在 e*******o 的大作中提到】
: 看了一下algernon 一个人搞的大杂烩。
: lz你比较各啥。
avatar
y*u
152 楼
软件做这么烂？为啥还能拿大包呢？百思不得其解啊

【在 m*****p 的大作中提到】
: 刚刚用了golang official的http benchmark，得到跟algernon同样的结果，说明还是
: golang的问题，即使用124个线程，性能也无法达到nginx在48核上98%的占用率，
: golang http benchmark只有30%占用率。
: https://github.com/golang/benchmarks/blob/master/http/http.go
avatar
m*p
154 楼
golang的http microbenchmark结果跟algernon一样，说明不是algernon问题，要不就
是golang需要额外调优，跟jvm一样https://github.com/golang/benchmarks/blob/
master/http/http.go

..

【在 S*******n 的大作中提到】
: algernon 性能比nginx慢几十倍，你就得出golang不行了…… 然后感叹硬件不好混...
: .无力吐槽
avatar
m*p
155 楼
但是http都这么弱，违背了当初golang的卖点：如java一样好用，类似c的性能。
其实性能比c弱多了，根本就不是类似好么。

【在 d******c 的大作中提到】
: 任何一个功能要做好都没有简单的
: 这个功能有现成的最好产品，golang根本没有动力去再做一遍，做的只是一个demo，为
: 了证明说它能做，实际不可能去和人家竞争，根本没有动力，没有资源去做，也没有多
: 少钱途，因为nginx已经push到极限了，很难有余地做的更好
: 软件界什么功能往往都有一堆实现，但是大部分都很难没法用，因为随便什么人都可以
: 开始个项目，但那根本不是产品
avatar
s*k
156 楼
同学，这些语言的目的就是让人不需要了解硬件底层都可以写，要不又懂CPU，又懂多
核，NUMA架构，还懂服务器设计的人才实在太少，怎么满足的了人民群众日益增长的需
求啊

【在 m*****p 的大作中提到】
: 我的主要觀點是硬件設計非常謹慎，我們改幾行RTL都得層層審批，一幫大牛評估，可
: 有可無的都被砍掉，於是硬件CPU廠家的性能差距越來越小。而軟件互聯網領域開發要
: 求糙快猛，實現同樣的功能，性能差異極大，導致各種方便麵語言橫行，golang是一個
: ，python更差，java也不咋滴。
: 我認為主要原因不是golang、python、java這些語言爛，而是用這些語言的大部分程序
: 員普遍缺乏軟件效率和CPU架構的基本常識，寫的東西爛。但這些並不妨礙他們的
: package大，福利更好。因為硬件領域狡兔死獵狗烹，做得太穩定就沒工作了。
:
:
: 你这个引申的结论就不合适了
:
: 搞framework，做软件工具的是要发明轮子，因为那是他们的市场，他们要创造
avatar
m*p
157 楼
对头，一个人随便写写，就能开一个项目，拿大包裹。
algernon支持的feature一大堆，却连基本的http static file都做不好。
说明很多开源项目的功能其实是只能看看而已，别当真。
golang不吹牛说跟C效率类似，就更没有人用了

【在 y**********u 的大作中提到】
: 其实magagop兄耿耿于怀的就是那帮傻x凭啥挣那么多了，百思不得其解
: 索南都不容易啊，大家一起转码拿大包不好吗？
avatar
s*k
158 楼
其实你可以去把它那个改好，就也能拿大包裹了：）
话说我看到很多benchmark都没有差10倍，C肯定是要快，不过你可以贴code看看是不是
哪里测试错了

【在 m*****p 的大作中提到】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
avatar
m*p
159 楼
NGINX就做得很好啊，给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
古怪的新语言：golang/rust/scala等等。

【在 s********k 的大作中提到】
: 同学，这些语言的目的就是让人不需要了解硬件底层都可以写，要不又懂CPU，又懂多
: 核，NUMA架构，还懂服务器设计的人才实在太少，怎么满足的了人民群众日益增长的需
: 求啊
avatar
m*p
160 楼
https://github.com/golang/benchmarks/blob/master/http/http.go
就是这个

【在 s********k 的大作中提到】
: 其实你可以去把它那个改好，就也能拿大包裹了：）
: 话说我看到很多benchmark都没有差10倍，C肯定是要快，不过你可以贴code看看是不是
: 哪里测试错了
avatar
y*u
161 楼
赞magagop兄这么坦诚，爱你

【在 m*****p 的大作中提到】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
avatar
y*u
162 楼
赞magagop兄这么坦诚，爱你

【在 m*****p 的大作中提到】
: 对头，一个人随便写写，就能开一个项目，拿大包裹。
: algernon支持的feature一大堆，却连基本的http static file都做不好。
: 说明很多开源项目的功能其实是只能看看而已，别当真。
: golang不吹牛说跟C效率类似，就更没有人用了
avatar
h*i
163 楼


【在 m*****p 的大作中提到】
: 軟件設計太重要了，今天測試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，性能可能下降上
: 百倍，而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
: 省錢的。大多數互聯網公司對硬件的要求是穩定就好，不關心性能。而他們自己的軟件
avatar
s*k
164 楼
有几个人能有做出Nginx水平啊，广大人民群众的需求这点少的牛人满足不了啊

【在 m*****p 的大作中提到】
: NGINX就做得很好啊，给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
: 古怪的新语言：golang/rust/scala等等。
avatar
s*k
165 楼
话说老兄觉得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

【在 m*****p 的大作中提到】
: NGINX就做得很好啊，给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
: 古怪的新语言：golang/rust/scala等等。
avatar
y*u
166 楼
> : https://docs.google.com/document/d/1At2Ls5_
> : fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit
竟然是Russ Cox，多年前经常在USACO上看到他的题解，往事如梦啊

【在 s********k 的大作中提到】
: 话说老兄觉得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
avatar
m*p
167 楼
罪魁祸首找到了：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
// 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)
}
}
avatar
y*u
168 楼
赞啊，转码浪费了，可是不转还是没钱，唉，人生好难

【在 m*****p 的大作中提到】
: 罪魁祸首找到了：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
avatar
f*t
169 楼
展开说说？

【在 m*****p 的大作中提到】
: 罪魁祸首找到了：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
avatar
m*p
170 楼
目前发现两大问题：
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] <... resumed="" sched_yield=""> ) = 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] <... resumed="" sched_yield=""> ) = 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] <... resumed="" write=""> ) = 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] <... resumed="" sched_yield=""> ) = 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 ...>
avatar
m*p
172 楼
golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
avatar
T*i
173 楼
pid 29010 貌似是GC thread。否则没法解释20us醒一次。
GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实也很高。一般
比20%要大。
当然我可以用空间换时间。但是那是customize allocators。

【在 m*****p 的大作中提到】
: golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
: 垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
: algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
avatar
g*t
174 楼
牛。GC你统计过longest pause什么的吗？
gc作者之一在这里
https://groups.google.com/forum/m/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8


: 罪魁祸首找到了：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



【在 m*****p 的大作中提到】
: golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
: 垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
: algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
avatar
g*t
175 楼
可预测性很重要。jvm最早时候我记得老死机吧？
c的话比较复杂，各种编译器各种优化什么的。


: pid 29010 貌似是GC thread。否则没法解释20us醒一次。

: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实
也很高
。一般

: 比20%要大。

: 当然我可以用空间换时间。但是那是customize allocators。



【在 T********i 的大作中提到】
: pid 29010 貌似是GC thread。否则没法解释20us醒一次。
: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实也很高。一般
: 比20%要大。
: 当然我可以用空间换时间。但是那是customize allocators。
avatar
s*k
176 楼
赞干货
两个问题
1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
话说完全可以提交一个PR了

JVM
herd

【在 m*****p 的大作中提到】
: 目前发现两大问题：
: 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
avatar
d*a
177 楼
如果用golang的syscall包，可以用SO_REUSEPORT吧。OS要支持SO_REUSEPORT。
这个比较对golang不太公平。golang可以做很多事情，nginx专长做web server。

【在 m*****p 的大作中提到】
: golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
: 垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
: algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。
avatar
d*a
178 楼
我的两分钱如下： :-)
1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
关，看起来象。
2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
futex调用。
我说的不一定对。

JVM
herd

【在 m*****p 的大作中提到】
: 目前发现两大问题：
: 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
avatar
d*a
179 楼
看了一下algernon源代码，好像就是用了golang的http包，在上面加了一层处理各种文
件类型...如果我的理解没错。
这样来做，不太可能有好的性能啊。:)

【在 d***a 的大作中提到】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
:
avatar
s*k
180 楼
所以说就是golang的这个包并没有做event based loop，还是直接狂开goroutine，所
以肯定比不过专门针对epoll做的IO密集型nginx？

【在 d***a 的大作中提到】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
:
avatar
s*k
181 楼
golfing 里面那个http package最好？

【在 d***a 的大作中提到】
: 看了一下algernon源代码，好像就是用了golang的http包，在上面加了一层处理各种文
: 件类型...如果我的理解没错。
: 这样来做，不太可能有好的性能啊。:)
avatar
m*p
182 楼
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有没有效果。

【在 d***a 的大作中提到】
: 我的两分钱如下： :-)
: 1. 我并不知道algernon是怎么实现的。从trace看，从一个打开的了socket里处理一个
: http get请求，algernon用了六七个线程来做，似乎algernon滥用了goroutine。
: goroutine用起来很方便，也许是这个原因？当然这是假设所有的线程都和这个请求相
: 关，看起来象。
: 2. SO_REUSEPORT和futex没有直接联系吧。goroutine多了，相互之间要同步，futex调
: 用就会多。SO_REUSEPORT的目的是快速重用网络端口吧，用了SO_REUSEPORT，不会减少
: futex调用。
: 我说的不一定对。
:
avatar
m*p
183 楼
内存设计得好，就不需要自动GC。内存泄露可以用工具各种测试，反而JVM GC的bug不
好弄，也不好优化。
Cassandra为了躲避GC，特地用JNI搞了offheap objects，malloc也换成jemalloc，这
不就是Cpp么？
JVM GC效率也是问题，G1比CMS慢好多，Shenandoah比G1更慢。。。
关于20%问题，对于软件工程师可能不算什么，对于硬件CPU，10%以上就可以决定跑分
输赢。

【在 s********k 的大作中提到】
: 赞干货
: 两个问题
: 1，关闭GC等于内存最后一直在那然后不会回收，你做一次test可能性能更好，但是肯
: 定不是长久之计，GC只有20%的overhead其实还不错了,拿完全手动内存分配的C和go的
: GC比肯定好，就像极致的手动挡当然比自动挡快，可以比较下JVM有GC下的overhead？
: 2. FUTEX, 是不是这个问题？https://github.com/golang/go/issues/23360
: 话说完全可以提交一个PR了
:
: JVM
: herd
avatar
m*p
184 楼
自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
都这么做了
只有亚麻和阿里是奇葩。

【在 g****t 的大作中提到】
: 可预测性很重要。jvm最早时候我记得老死机吧？
: c的话比较复杂，各种编译器各种优化什么的。
:
:
: pid 29010 貌似是GC thread。否则没法解释20us醒一次。
:
: GC overhead如果20%的话，其实是很不错的。C的内存管理overhead其实
: 也很高
: 。一般
:
: 比20%要大。
:
: 当然我可以用空间换时间。但是那是customize allocators。
:

avatar
s*k
185 楼
这些大公司里面，CPP，java,golang都用的（当然软软加上C#），CPP是好，但是真是
顶级人才满足不了人民群众日益增长需求，要精通太难了。
做大规模项目
human is always the least scalable in your system

【在 m*****p 的大作中提到】
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
: 都这么做了
: 只有亚麻和阿里是奇葩。
avatar
s*k
186 楼
你看看这个？
https://github.com/kavu/go_reuseport
https://github.com/libp2p/go-reuseport

【在 m*****p 的大作中提到】
: 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有没有效果。
avatar
w*z
188 楼
绝大部分的应用对实时性的要求是可以容忍 偶尔 long gc。 一般互联网公司 SLA 99.
99% 在 large distributed system 里，别说 long paused GC, 整个机器不见了的事
情时刻在发生。客户端容错做好就行了，一个 request timeout, 下一个 request 就
去别的node

：自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
：我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
avatar
m*p
189 楼
其實不是這樣的，這個問題叫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.
华为

【在 w**z 的大作中提到】
: 绝大部分的应用对实时性的要求是可以容忍 偶尔 long gc。 一般互联网公司 SLA 99.
: 99% 在 large distributed system 里，别说 long paused GC, 整个机器不见了的事
: 情时刻在发生。客户端容错做好就行了，一个 request timeout, 下一个 request 就
: 去别的node
:
: ：自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
: ：我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百度华为
avatar
y*u
190 楼
牛逼，请收下我的膝盖

【在 m*****p 的大作中提到】
: 其實不是這樣的，這個問題叫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
:
avatar
s*k
191 楼
赞资料
现在golang运行环境大部分其实更复杂，很多事在cloud上的VM做的，VM针对bare
linux的调度就是多了一层，如果用container（绝大部分golang都用k8s或者其他
container的部署技术）比如k8s，那么一个VM只是一个node，上面还有很多pod，又加
了一层隔离，其中的网络配置方式也可以有多种。所以这个性能优化还真是一个大课题
。搞定这个绝对大包不愁啊
magagop 你底层系统经验这么好，绝对应该搞搞这个

【在 m*****p 的大作中提到】
: 其實不是這樣的，這個問題叫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
:
avatar
y*j
192 楼
关于Go的多线程GC慢的问题，这里有一个解释：
https://blog.cloudflare.com/go-dont-collect-my-garbage/
基本就是线程很多的时候，GC频繁回收大量的临时变量，导致性能提升不大。
他调节了GOGC的参数，最后能够充分利用24核，性能提高23倍。


: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。

: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软
腾讯百
度华为

: 都这么做了

: 只有亚麻和阿里是奇葩。



【在 m*****p 的大作中提到】
: 其實不是這樣的，這個問題叫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
:
avatar
y*j
193 楼
关于Golang, 我感觉是CPP的一个简化版，但是砍得太猛了，也许留下stack 上的自动
变量会好一些。至少减轻GC的压力。


: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。

: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软腾讯百
度华为

: 都这么做了

: 只有亚麻和阿里是奇葩。



【在 m*****p 的大作中提到】
: 其實不是這樣的，這個問題叫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
:
avatar
m*p
194 楼
剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。
avatar
T*i
195 楼
俺一直都说，C#是最好的语言。。。。

【在 m*****p 的大作中提到】
: 剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
: 有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。
avatar
m*p
197 楼
这里面讲了，为什么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).
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.
avatar
m*p
198 楼
多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且还能非
线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。

【在 y*j 的大作中提到】
: 关于Go的多线程GC慢的问题，这里有一个解释：
: https://blog.cloudflare.com/go-dont-collect-my-garbage/
: 基本就是线程很多的时候，GC频繁回收大量的临时变量，导致性能提升不大。
: 他调节了GOGC的参数，最后能够充分利用24核，性能提高23倍。
:
:
: 自动GC的问题就是为了增加可预测性，牺牲性能，参考G1GC。
:
: 我一直想不通，需要可预测性的程序为什么不直接上Cpp？毕竟FG和微软
: 腾讯百
: 度华为
:
: 都这么做了
avatar
y*j
199 楼
把GC完全关掉，时间一长，非耗尽内存空间不可。


: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且
还能非

: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。



【在 m*****p 的大作中提到】
: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且还能非
: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
avatar
b*s
200 楼
golang + docker may be the best practice

【在 s********k 的大作中提到】
: 赞资料
: 现在golang运行环境大部分其实更复杂，很多事在cloud上的VM做的，VM针对bare
: linux的调度就是多了一层，如果用container（绝大部分golang都用k8s或者其他
: container的部署技术）比如k8s，那么一个VM只是一个node，上面还有很多pod，又加
: 了一层隔离，其中的网络配置方式也可以有多种。所以这个性能优化还真是一个大课题
: 。搞定这个绝对大包不愁啊
: magagop 你底层系统经验这么好，绝对应该搞搞这个
avatar
y*j
201 楼
Csharp 也是我的favorite。java和它相比很粗糙，cpp 和它相比又太复杂混乱。


: 俺一直都说，C#是最好的语言。。。。



【在 T********i 的大作中提到】
: 俺一直都说，C#是最好的语言。。。。
avatar
m*p
202 楼
CSharp在Linux、非x86架构下有性能很好的编译器和库么？
听说.NET开源的只是核心库，不是全部，不知道未来怎样。还有IDE和社区，这也很重
要。

【在 y*j 的大作中提到】
: Csharp 也是我的favorite。java和它相比很粗糙，cpp 和它相比又太复杂混乱。
:
:
: 俺一直都说，C#是最好的语言。。。。
:

avatar
m*p
203 楼
关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。

【在 y*j 的大作中提到】
: 把GC完全关掉，时间一长，非耗尽内存空间不可。
:
:
: 多谢回复，这个GC问题正是我碰到的，没想到GOGC还能设置超过100的数，而且
: 还能非
:
: 线性优化，真是个坑，看来GOGC任重道远啊。我本以为GOGC=off就万事大吉了。
:

avatar
y*j
204 楼
我自己瞎猜的，如果内存一点也不释放的话，会损失Cache locality, 内存空间会碎片
化。


: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。



【在 m*****p 的大作中提到】
: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。
avatar
d*a
205 楼
内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。

【在 y*j 的大作中提到】
: 我自己瞎猜的，如果内存一点也不释放的话，会损失Cache locality, 内存空间会碎片
: 化。
:
:
: 关键是GOGC=off性能比GOGC=2400差，不知道为什么。。。
:

avatar
s*k
206 楼
用.Net core,比之前那个overhead很高的.net好很多，关键是LINQ比Java 新的那个
stream好用啊

【在 m*****p 的大作中提到】
: CSharp在Linux、非x86架构下有性能很好的编译器和库么？
: 听说.NET开源的只是核心库，不是全部，不知道未来怎样。还有IDE和社区，这也很重
: 要。
avatar
s*k
207 楼
page fault不是忙IO把，是swap出去之后重新load进TLB很花时间？

害。

【在 d***a 的大作中提到】
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。
avatar
s*k
208 楼
如果本来就是在VM上面再加pod上运行container，这个NUMA的作用还会很大吗？因为没
法控制底层的OS，golang也很难做好scheduler把？

miss

【在 m*****p 的大作中提到】
: 这里面讲了，为什么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).
avatar
s*k
209 楼
我觉得你是不是可以换个方法实验
你目前的实验室基于一个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

【在 m*****p 的大作中提到】
: 这里面讲了，为什么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).
avatar
y*j
210 楼
看那个报告的样子，应该还没有到经常page fault 的地步，否则性能会下降得非常厉
害。


: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss
更厉害。



【在 d***a 的大作中提到】
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss更厉害。
avatar
d*a
211 楼
从内存里做TLB refill大约是150-200个纳秒左右吧，page fault的延迟是毫秒级了。

【在 s********k 的大作中提到】
: page fault不是忙IO把，是swap出去之后重新load进TLB很花时间？
:
: 害。
avatar
d*a
212 楼
是的，不过如果把GC关掉长时间运行下去，page fault会增加的。

miss

【在 y*j 的大作中提到】
: 看那个报告的样子，应该还没有到经常page fault 的地步，否则性能会下降得非常厉
: 害。
:
:
: 内存用的太多，会增加page fault rate。I/O系统忙起来，比频繁的cache miss
: 更厉害。
:

avatar
s*k
213 楼
哦所以你意思是swap到disk上了？不做GC确实有可能，不过如果GC下多个goroutine频
繁调度不知道会不会频繁重新load TLB，golang的schedule好像在避免这个

【在 d***a 的大作中提到】
: 从内存里做TLB refill大约是150-200个纳秒左右吧，page fault的延迟是毫秒级了。
avatar
m*p
214 楼
.NET Core 2目前只支持Windows下的arm64，等Linux下也有arm64再開始轉吧。
Mono支持Linux的arm64，但性能應該不行（跟gcc 7.2比）

【在 s********k 的大作中提到】
: 用.Net core,比之前那个overhead很高的.net好很多，关键是LINQ比Java 新的那个
: stream好用啊
avatar
m*p
215 楼
我們試過lxc和kvm，如果不是Xeon的CPU的話，性能會再下降一個數量級（因為host-
guest communication in kernel code），而且裡面坑特別多，就不細講了。另外
docker和k8s對非x86的支持也不是很好。
虛擬化和容器不是silverbullet，至少在性能上說。AWS最近就在去VM化，參考AWS
Nitro和baremetal EC2。如果同時用虛擬化和容器，或者雙重虛擬化，性能就別指望了。

VM
http

【在 s********k 的大作中提到】
: 我觉得你是不是可以换个方法实验
: 你目前的实验室基于一个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
avatar
s*k
216 楼
我的意思是实际上运行环境很多事虚拟化的，你把NGINX跑到VM上是不是也会性能下降.
VM肯定性能下降，但是大家（Golang http server 和NGINX）都下降下，你再比较下呢？
？关于去VM倒是又是一个课题。

了。

【在 m*****p 的大作中提到】
: 我們試過lxc和kvm，如果不是Xeon的CPU的話，性能會再下降一個數量級（因為host-
: guest communication in kernel code），而且裡面坑特別多，就不細講了。另外
: docker和k8s對非x86的支持也不是很好。
: 虛擬化和容器不是silverbullet，至少在性能上說。AWS最近就在去VM化，參考AWS
: Nitro和baremetal EC2。如果同時用虛擬化和容器，或者雙重虛擬化，性能就別指望了。
:
: VM
: http
avatar
m*p
217 楼
Nginx下降更多，都用VM結果是nginx和golang的差距比裸機小，從原來的10倍或100倍
下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
多，這也是亞馬遜買CPU公司做硬件的原因。

降.
呢？

【在 s********k 的大作中提到】
: 我的意思是实际上运行环境很多事虚拟化的，你把NGINX跑到VM上是不是也会性能下降.
: VM肯定性能下降，但是大家（Golang http server 和NGINX）都下降下，你再比较下呢？
: ？关于去VM倒是又是一个课题。
:
: 了。
avatar
d*a
218 楼
你用的nginx和golang algernon是I/O intensive的workload。如果跑compute
intensive的workload，VM和裸机会很接近。
看起来你们用的硬件，对VM中的I/O部分的支持不好啊，不应该影响这么大。有可能是I
/O虚拟化的硬件支持不好。感觉你们的系统，要调的地方很多，工作量很大。:)

【在 m*****p 的大作中提到】
: Nginx下降更多，都用VM結果是nginx和golang的差距比裸機小，從原來的10倍或100倍
: 下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
: 多，這也是亞馬遜買CPU公司做硬件的原因。
:
: 降.
: 呢？
avatar
s*k
219 楼
对啊，我就是这个意思，专门针对单机优化上，最接近底层的C做出来的还是肯定好，
但是很少golang是在bare的单机上运行，大部分都是distributed的VM上

【在 m*****p 的大作中提到】
: Nginx下降更多，都用VM結果是nginx和golang的差距比裸機小，從原來的10倍或100倍
: 下降到一半或幾倍，可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
: 多，這也是亞馬遜買CPU公司做硬件的原因。
:
: 降.
: 呢？
avatar
T*i
220 楼
其实所谓云架构，大多数是没啥必要的。
VM慢了一个数量级以上，无论如何都不能justify。
被人收割骗钱而已。

【在 s********k 的大作中提到】
: 对啊，我就是这个意思，专门针对单机优化上，最接近底层的C做出来的还是肯定好，
: 但是很少golang是在bare的单机上运行，大部分都是distributed的VM上
avatar
p*u
221 楼
云本来就是为了节省IT support的costs，不是提高性能。

【在 T********i 的大作中提到】
: 其实所谓云架构，大多数是没啥必要的。
: VM慢了一个数量级以上，无论如何都不能justify。
: 被人收割骗钱而已。
avatar
s*k
222 楼
追求性能肯定要自己做，但是大部分应用上云架构主要是方便，开启服务，scale，
monitor，啥都方便，等到服务做大了，再专门自己搞DC做

【在 T********i 的大作中提到】
: 其实所谓云架构，大多数是没啥必要的。
: VM慢了一个数量级以上，无论如何都不能justify。
: 被人收割骗钱而已。
avatar
m*n
223 楼
你和软件工程师只有一个本质差别：
你不掌握生产资料，所以只能被剥夺剩余价值
卡尔 马克思
avatar
j*h
224 楼
不明白。软件工程师不是也在被剥夺剩余价值？
本来软件既是生产资料又是劳动产出，结果给来了个开源。
唉唉唉

【在 m*****n 的大作中提到】
: 你和软件工程师只有一个本质差别：
: 你不掌握生产资料，所以只能被剥夺剩余价值
: 卡尔 马克思
avatar
N*r
225 楼

你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司

【在 j*******h 的大作中提到】
: 不明白。软件工程师不是也在被剥夺剩余价值？
: 本来软件既是生产资料又是劳动产出，结果给来了个开源。
: 唉唉唉
avatar
j*h
226 楼
nginx

【在 N*****r 的大作中提到】
:
: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司
avatar
f*2
227 楼
开源是牛逼但不被承认的社会底层的唯一出路，类似十月革命掀桌子


: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司



【在 N*****r 的大作中提到】
:
: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司
avatar
f*t
228 楼
啥出路？做高质量开源能挣大钱？

【在 f******2 的大作中提到】
: 开源是牛逼但不被承认的社会底层的唯一出路，类似十月革命掀桌子
:
:
: 你见过什么重要的东西做的很完美的搞开源的， 除了sun那个傻逼公司
:

avatar
m*n
229 楼
R就是这么搞的
一边开源
一边弄个收费高级版
还有Qt系列也是如此

【在 f*******t 的大作中提到】
: 啥出路？做高质量开源能挣大钱？
avatar
b*t
230 楼
algernon三年四百多个星的野鸡库也敢用
想用go webserver， 试试caddy
avatar
l*p
231 楼
速度不是唯一的要求

【在 T********i 的大作中提到】
: 其实所谓云架构，大多数是没啥必要的。
: VM慢了一个数量级以上，无论如何都不能justify。
: 被人收割骗钱而已。
avatar
m*p
232 楼
IO虛擬化目前只有intel的vt-d、sr-iov、apic-v做得很好，其他非x86架構都不行，因
為軟件問題。別看白皮書介紹得簡單，裡面非常複雜，非常不好做，坑特別多。性能只
有xeon可以接近裸機，這就是xeon佔領99.9%市場的原因，amd都不行。

是I

【在 d***a 的大作中提到】
: 你用的nginx和golang algernon是I/O intensive的workload。如果跑compute
: intensive的workload，VM和裸机会很接近。
: 看起来你们用的硬件，对VM中的I/O部分的支持不好啊，不应该影响这么大。有可能是I
: /O虚拟化的硬件支持不好。感觉你们的系统，要调的地方很多，工作量很大。:)
avatar
w*z
233 楼
现在有自己DC的公司已经没几个了。以后也不太会有新的公司用自己DC了

【在 s********k 的大作中提到】
: 追求性能肯定要自己做，但是大部分应用上云架构主要是方便，开启服务，scale，
: monitor，啥都方便，等到服务做大了，再专门自己搞DC做
avatar
s*k
234 楼
做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在cloud
上，比如netflix，但是99%公司还没到追求极致性能就死掉了

【在 w**z 的大作中提到】
: 现在有自己DC的公司已经没几个了。以后也不太会有新的公司用自己DC了
avatar
w*z
235 楼
你提到的那些都是在 cloud 流行之前开始的，不存在从 cloud 转到 自己 DC 的。公
司规模越大，要转的代价就越大， 真不如乖乖给 aws 写支票。新的有一定规模的公司
，除了 uber, 都在云上。

：做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在
cloud
：上，比如netflix，但是99%公司还没到追求极致性能就死掉了
avatar
f*t
236 楼
Dropbox转到自己的DC了

【在 w**z 的大作中提到】
: 你提到的那些都是在 cloud 流行之前开始的，不存在从 cloud 转到 自己 DC 的。公
: 司规模越大，要转的代价就越大， 真不如乖乖给 aws 写支票。新的有一定规模的公司
: ，除了 uber, 都在云上。
:
: ：做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在
: cloud
: ：上，比如netflix，但是99%公司还没到追求极致性能就死掉了
avatar
w*z
237 楼
that was a bold move.
During its early years, Dropbox ran its entire operation on Amazon’s cloud
computing service. But more recently it has moved much of its
infrastructure off AWS to cut down on costs. The company said that in 2016,
it was able to shrink its cost of revenue by $35.1 million as part of its
AWS migration, which it refers to as “Infrastructure Optimization.” As
tech publication GeekWire notes, the data center move help saved
Dropbox about $75 million over a two-year period.

：Dropbox转到自己的DC了
：
avatar
m*p
238 楼
感覺golang的默認goroutine設計模式有問題，下面是golang http microbenchmark的
perf report：
60.24% [kernel] [k] arch_cpu_idle
6.43% [kernel] [k] _raw_spin_lock
4.40% http [.] runtime.runqgrab
2.19% http [.] runtime.findrunnable
感覺golang如果有很多goroutine和thread，大部分時間都會用在runtime.runqgrab上
，然後runtime.futex會過載，導致系統60% CPU都是idle
avatar
m*p
239 楼
在runtime/proc.go裡面有很多lock(&sched.lock)，
例如把goroutine放到global runq裡面就需要lock
func goschedImpl(gp *g) {
status := readgstatus(gp)
if status&^_Gscan != _Grunning {
dumpgstatus(gp)
throw("bad g status")
}
casgstatus(gp, _Grunning, _Grunnable)
dropg()
lock(&sched.lock)
globrunqput(gp)
unlock(&sched.lock)
schedule()
}
sched是runtime2.go裡面的一個全局變量
var (
allglen uintptr
allm *m
allp []*p // len(allp) == gomaxprocs; may change at safe
points, otherwise immutable
allpLock mutex // Protects P-less reads of allp and all writes
gomaxprocs int32
ncpu int32
forcegc forcegcstate
sched schedt
newprocs int32
)
schedt是一個type struct
type schedt struct {
// accessed atomically. keep at top to ensure alignment on 32-bit
systems.
goidgen uint64
lastpoll uint64
lock mutex
// Global runnable queue.
runqhead guintptr
runqtail guintptr
runqsize int32
// Global cache of dead G's.
gflock mutex
// Central cache of sudog structs.
sudoglock mutex
// Central pool of available defer structs of different sizes.
deferlock mutex
}
lock mutex就是32位變量
// Mutual exclusion locks. In the uncontended case,
// as fast as spin locks (just a few user-level instructions),
// but on the contention path they sleep in the kernel.
// A zeroed Mutex is unlocked (no need to initialize each lock).
type mutex struct {
// Futex-based impl treats it as uint32 key,
// while sema-based impl as M* waitm.
// Used to be a union, but unions break precise GC.
key uintptr
}
func lock實現極其簡單，就是先CAS看鎖了沒，然後spinning一會兒，最後futexsleep：
// This implementation depends on OS-specific implementations of
//
// futexsleep(addr *uint32, val uint32, ns int64)
// Atomically,
// if *addr == val { sleep }
// Might be woken up spuriously; that's allowed.
// Don't sleep longer than ns; ns < 0 means forever.
//
// futexwakeup(addr *uint32, cnt uint32)
// If any procs are sleeping on addr, wake up at most cnt.
func lock(l *mutex) {
// Speculative grab for lock.
v := atomic.Xchg(key32(&l.key), mutex_locked)
if v == mutex_unlocked {
return
}
if ncpu > 1 {
spin = active_spin
}
for {
// Try for lock, spinning. procyield(active_spin_cnt)
// Try for lock, rescheduling. osyield()
// Sleep.
v = atomic.Xchg(key32(&l.key), mutex_sleeping)
if v == mutex_unlocked {
return
}
wait = mutex_sleeping
futexsleep(key32(&l.key), mutex_sleeping, -1)
}
}
avatar
m*p
240 楼
所以我前面提到的golang性能的第二個問題不是algernon獨有，也是golang區別於c的
最大特點：goroutine。目前golang最多能有一千萬併發goroutines，換成內存也就是
幾十GB，對於AWS上的只有幾十GB的VM小系統估計夠用了，但是對於多路1TB共享內存大
系統，golang目前沒有NUMA調度架構顯然不行。
測試golang http，其實變成了測試Linux sys_futex()，唉。。。
avatar
c*f
241 楼
现在只有很极致的公司才追求那10%的性能优化 更多的追求实用 短平快
人家根本不care这点区别 再堆机器就是了 机器多少钱 我请人回来弄类似nginx的
memory trick得花多少钱 以后怎么维护？ 升级 更新怎么办？
就想之前碰到一个公司 所有的http服务都是in house的 结果碰到H2 自己做的基于LVS
的链接toss back不能用了不说 连H2的功能的prototype都要做好久
但是市场需求就是马上要H2 你怎么办？ 只能去掉自己in house的LB
所有在用人成本 今后维护 各方面来说 真的可以追求那最顶点性能优化的公司也就没
几个
现在K8S这么热 大家都网上迁呢 谁在乎调度器和API被干爆了如何 多加几个就是了
avatar
m*p
242 楼
看清我的結論：性能差別10倍不止，不是10%，如果是50%，我都會說golang很好。但是
差距1000%，我就呵呵了。

LVS

【在 c****f 的大作中提到】
: 现在只有很极致的公司才追求那10%的性能优化 更多的追求实用 短平快
: 人家根本不care这点区别 再堆机器就是了 机器多少钱 我请人回来弄类似nginx的
: memory trick得花多少钱 以后怎么维护？ 升级 更新怎么办？
: 就想之前碰到一个公司 所有的http服务都是in house的 结果碰到H2 自己做的基于LVS
: 的链接toss back不能用了不说 连H2的功能的prototype都要做好久
: 但是市场需求就是马上要H2 你怎么办？ 只能去掉自己in house的LB
: 所有在用人成本 今后维护 各方面来说 真的可以追求那最顶点性能优化的公司也就没
: 几个
: 现在K8S这么热 大家都网上迁呢 谁在乎调度器和API被干爆了如何 多加几个就是了
avatar
f*t
243 楼
别钻牛角尖了，找到一个特殊的应用说性能差10倍以上，作为技术研究是好的，但没有
实际意义。用Go写backend service的公司很多，碰到性能瓶颈，总会有fix或者
workaround。如果真的需要10倍性能，而Go无论如何都达不到的，就换更合适的语言写
对应的模块唄。

【在 m*****p 的大作中提到】
: 看清我的結論：性能差別10倍不止，不是10%，如果是50%，我都會說golang很好。但是
: 差距1000%，我就呵呵了。
:
: LVS
avatar
m*p
244 楼
http的goroutine和gogc不是特殊應用，是golang做web後台的基礎好麼，回去先看看什
麼是goroutine和gogc再來回復。這兩個問題非常不好workaround，是golang區別於cpp
語言的根子。

【在 f*******t 的大作中提到】
: 别钻牛角尖了，找到一个特殊的应用说性能差10倍以上，作为技术研究是好的，但没有
: 实际意义。用Go写backend service的公司很多，碰到性能瓶颈，总会有fix或者
: workaround。如果真的需要10倍性能，而Go无论如何都达不到的，就换更合适的语言写
: 对应的模块唄。
avatar
g*t
245 楼
做web后台那你就和java比啊。和cpp较劲为哪般呢。。。
任何语言和c／cpp，fortran，pascal比性能都没什么意义。

cpp

【在 m*****p 的大作中提到】
: http的goroutine和gogc不是特殊應用，是golang做web後台的基礎好麼，回去先看看什
: 麼是goroutine和gogc再來回復。這兩個問題非常不好workaround，是golang區別於cpp
: 語言的根子。
avatar
p*y
246 楼
这个说的不错

【在 w**z 的大作中提到】
: 你提到的那些都是在 cloud 流行之前开始的，不存在从 cloud 转到 自己 DC 的。公
: 司规模越大，要转的代价就越大， 真不如乖乖给 aws 写支票。新的有一定规模的公司
: ，除了 uber, 都在云上。
:
: ：做到500B市值以上一般都会有（FGAM等），100B估计开始考虑但是还是可以全在
: cloud
: ：上，比如netflix，但是99%公司还没到追求极致性能就死掉了
avatar
m*n
247 楼
是不是这样理解
goroutine只能做到支持单机多核
例如8核还好用，32核效率就一般，再多了就扯了
分布式计算必须得换map reduce?

cpp

【在 m*****p 的大作中提到】
: http的goroutine和gogc不是特殊應用，是golang做web後台的基礎好麼，回去先看看什
: 麼是goroutine和gogc再來回復。這兩個問題非常不好workaround，是golang區別於cpp
: 語言的根子。
avatar
m*n
248 楼
别的行业的剥削基础是在于劳动者必须依附于某个大佬的公司才能开展工作，因为缺乏
完成工作成果必备的生产资料，而代码工作者不需要。实在不爽了，自己出来单干或几
个人合伙开个小公司都行，不需要缺它不可的需要大额资金投入的生产资料，例如刻芯
片的机器。
所以码工是跳槽最频繁的职业，依然工资最高。很多老板反而是弱势群体。

【在 j*******h 的大作中提到】
: 不明白。软件工程师不是也在被剥夺剩余价值？
: 本来软件既是生产资料又是劳动产出，结果给来了个开源。
: 唉唉唉
相关阅读
A thread question请教一个关于字符指针的简单问题[转载] 问一个C++下计时的问题Re: 一个小c++(stl) 的问题有没有for VC的Math 库?Afx window,如何获得control handle???? i m confusedRe: [转载] Google desktop中HTML文件的thumbnail怎么将linked list 存储到文件中去呀timer(linux/g++)?Re: [转载] 问一问题Re: 如何调用sysconf()?respin 是什么意思？a question about ASP.NETgood C++ open source project?[转载] Re: 问个土问题吧gmail 是怎么实现那些html功能的how to create interface "operator=="谢谢大家！One More Question! Re: C 程序计算结果关于fscanf格式化读取的问题.
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章，不代表同意其说法或描述，仅为提供更多信息，也不构成任何建议。文章信息的合法性及真实性由其作者负责，与Redian.news及其运营公司无关。欢迎投稿，如发现稿件侵权，或作者不愿在本网发表文章，请版权拥有者通知本网处理。