d******e
发帖数: 2265 | 1 should be a simple iterator like this.
def from_x_stream(x):
count = x
while (true):
count += 1
yield count |
|
d****n
发帖数: 1637 | 2 http://play.golang.org/p/vS409gRveG
开20个worker，多用几个 电脑，当你 存xml时候注意一下duplicates就搞定了。指定
比你的 python快
// In this example we'll look at how to implement
// a _worker pool_ using goroutines and channels.
package main
import "fmt"
import "net/http"
import "log"
import "io/ioutil"
// Here's the worker, of which we'll run several
// concurrent instances. These workers will receive
// work on the `jobs` channel and send the corresponding
// results on `results`. We'll sleep a second per job to
// simulate... 阅读全帖 |
|
d****n
发帖数: 1637 | 3 fyi: worker is goroutine |
|
z****e
发帖数: 54598 | 4
用点脑子，go底层就是thread
goroutine也不是什么新鲜玩意
如果你懂obj c的话，这种东西早就在ios编程上出现过了
这种写法远比worker简单直接
你真要上worker的话，有本事跟vert.x比比啊
json被秒得连渣都不剩，xml自己试试啊
就怕你不敢试 |
|
k****i
发帖数: 101 | 5 - non-blocking(async) i/o 底层先要支持，如epoll等
- 应用层有多种实现，node用single threaded eventloop，go用goroutine，c#有
async/await，java有threadpool如某些async client libs，也有eventloop如vertx，
这些都能解决io-bound request/connection:thread=1：1的问题。 |
|
|
|
w***g
发帖数: 5958 | 8 那个golib有点意思。不知道操统的阻塞操作怎么处理。
就go而言，runtime应该能知道哪些操作会阻塞，然后可以自动切换goroutine。
但是如果用C/C++，直接调用操统接口，比如select，
golib怎么知道？ |
|
|
|
d****n
发帖数: 1637 | 11 nodejs file IO 就只能嘿嘿了，写起来别扭，读起来不爽。
golang 一点也不怕。完全没压力。8个goroutine出去，一个channel等回来，你有多少
cpu,我就能扩展多少。
nodejs 就会，
setImmediate(function(){
})
要不就async.parallel([])
有人提promise,说高级，我看半斤八两。debug时候就挠头皮吧。 |
|
w***g
发帖数: 5958 | 12 coroutine和monitor是两个基本上被实践抛弃了的概念。python的
yield其实是标准的coroutine，但是一般讲python的资料都会把它
叫做iterator或者generator。现在还在提coroutine的，一般都是
哗众取宠混淆视听。
如何区别coroutine和thread的一个标准就是：coroutine的yield
返回后，执行权落在那一行程序是确定的，由程序的
逻辑决定。thread yield/preempt了以后，执行权落在那一行程序是
不确定的，由thread scheduler决定的。即使是cooperative thread
跑在一个CPU上，执行权落哪儿也是不确定的。
goroutine就是一种light-weighted thread，不是coroutine。
wikipedia上那篇coroutine也是概念非常混淆乱讲一通。其实只要
程序写对了，抠概念屁用没有。我书读太多脑子有点坏掉了。 |
|
T********i
发帖数: 2416 | 13 coroutine和iterator根本就是两个概念。coroutine有自己的stack，yield以后也要有
context switch，iterator不一定。
基于coroutine可以有multi-task和scheduler。因此coroutine yield以后，可以直接
回到scheduler，执行权落在那一行程序是由scheduler决定，不一定是确定的。
因此coroutine和thread很像。但是就是yield的含义不一样。我不确定std::thread实
现coroutine是不是一个好主意？因为为了能够做到兼容，因为thread多任务不需要
yield也能保证响应，但是coroutine必须yield，因此为了保证兼容性长任务要插入
yield才能保证响应，但是会带来额外的负担。
goroutine这种就是coroutine，context switch只需要切换stack和register，不需要
flush cache，switch TLB，security check，这些都是微秒级别的操作。而且内置
scheduler
，还要在I/O函数外面包上w... 阅读全帖 |
|
g****t
发帖数: 31659 | 14 的goroutine和channel看上去非常厉害啊
https://talks.golang.org/2010/io/talk.pdf
不过自从多年前Lucent破产，贝尔实验室解散之后，
我已经彻底觉悟了。凡是讲：think in xxx的90%都是老骗子。
这种东西搞的复杂是为了让几千万用户用着都不出问题。
但是如果是个人用户，其实是不是自己c写个yield和内存快照，几个锁定更方便呢?
新模型学太多，可能大脑会出问题啊
Rob pike的话:
concurrency不是关于performance的东西，是程序的新组织方式
我看改成goto也可以
goto不是关于performance的东西，是程序的新组织方式 |
|
|
k****i
发帖数: 101 | 16 看到没
牛不是巧合
基础。。。
：channel是p9的东西。go其实就是goroutine, 我以前专门写过的，帖子我主页上有存
档。
： |
|
a*****e
发帖数: 1700 | 17 GHC 的 M:N 轻线程调度比 goroutine 早很多年 |
|
w***g
发帖数: 5958 | 18 是bug吧。如果是go的bug, 修好了可是大credit。不过我觉得是楼主参数没设好，资源
用光了。
：理论上用 goroutine 来替代 thread，
：用 channel 协助调度是比较干净的一个模型。 |
|
S*A
发帖数: 7142 | 19 这个我们的确有这个需求，至少要 demo 能够处理这样的流量。
如果是我一个人写和维护就直接 C + epoll 橹了，而且保证是最优化的。
这个 go 的头不是我开的，但是也不是完全没有解就是了。
其实说白了就是放弃 goroutine N：1 tcp 的对应关系。
然后把 go 当 C 写，自己处理 server pool，epoll 这些。
网上有人讨论这个基本上是这个结果。
java 就算了吧。我这个不是典型的 web 后段应用，
有其他考虑，java 基本上不考虑了。
B |
|
s********k
发帖数: 6180 | 20 Go哪里算鼓励blocking编程啊，完全相反吧，channel你不能理解成block，理解成更好
manage的lock更合适，你这么一说感觉是不是你的channel buffer没有开够啊，比如你
的req和rsp各自goroutine，但是中间用一个channel share info，如果channel
buffer不够，总是会出现producer、consumer这样问题吧 |
|
S*A
发帖数: 7142 | 21
Go 和 python 性能还是强太多，不是一个级别的东西。
我就是想说这个，goroutine 直接简单粗暴上了数量
效果是不好的。
还没有到 DPDK 这样变态。而且 DPDK 移植性比较弱。
调硬件平台。 |
|
s********k
发帖数: 6180 | 22 看了下你的逻辑，你现在这样实现？
go func(recv socket)?
如果成这样是不是更好？
func recv(socket){
for pub in range publishers{
go func(service)
}
}
就是说把goroutine用在业务逻辑，不是IO上？
epoll
IO
go |
|
S*A
发帖数: 7142 | 23
不知道你想如何改这个。现在问题是有 N 个 tcp 连接。
每一个发送都会有可能 block。如果你里面那个 for
loop 也是 N 个元素的话，并没有节省 goroutine。
如果里面那个 for loop service， << N 的话，那就是
发送的时候是等一个 tcp 发完了才发下一个，失去了
并发性。发送的数据包比一个Ethernet 包大多了。
一个 tcp 发玩一组才发下一个的带宽用不满。 |
|
s********k
发帖数: 6180 | 24 可能没写清楚，就是不用go做TCP recv这一套交给epoll，你不是接受回来数据之后要
发送到message queue/pub service？把这一部分做成goroutine？ |
|
|
发帖数: 1 | 26 目前发现两大问题：
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 290... 阅读全帖 |
|
发帖数: 1 | 27 golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。 |
|
s********k
发帖数: 6180 | 28 所以说就是golang的这个包并没有做event based loop，还是直接狂开goroutine，所
以肯定比不过专门针对epoll做的IO密集型nginx？ |
|
发帖数: 1 | 29 剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。 |
|
s********k
发帖数: 6180 | 30 哦所以你意思是swap到disk上了？不做GC确实有可能，不过如果GC下多个goroutine频
繁调度不知道会不会频繁重新load TLB，golang的schedule好像在避免这个 |
|
发帖数: 1 | 31 在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
... 阅读全帖 |
|
发帖数: 1 | 32 目前发现两大问题：
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 290... 阅读全帖 |
|
发帖数: 1 | 33 golang到目前为止也不支持SO_REUSEPORT，这个至少比NGINX慢5倍。
垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
algernon建立在golang上，golang在性能设计上有问题，algernon也没办法。 |
|
s********k
发帖数: 6180 | 34 所以说就是golang的这个包并没有做event based loop，还是直接狂开goroutine，所
以肯定比不过专门针对epoll做的IO密集型nginx？ |
|
发帖数: 1 | 35 剛才看了看goroutine的評論，發現Csharp的fiber和Java的loom都很有競爭力，Cpp也
有Facebook的Folly庫支持fiber，看來狗家go確實沒有軟家Csharp語言能力強。 |
|
s********k
发帖数: 6180 | 36 哦所以你意思是swap到disk上了？不做GC确实有可能，不过如果GC下多个goroutine频
繁调度不知道会不会频繁重新load TLB，golang的schedule好像在避免这个 |
|
发帖数: 1 | 37 在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
... 阅读全帖 |
|
m*****n
发帖数: 3575 | 38 是不是这样理解
goroutine只能做到支持单机多核
例如8核还好用，32核效率就一般，再多了就扯了
分布式计算必须得换map reduce?
cpp |
|
|
s********k
发帖数: 6180 | 40 http://morsmachine.dk/netpoller
再补同样的一篇
in Go, all I/O is blocking. The Go ecosystem is built around the idea that
you write against a blocking interface and then handle concurrency through
goroutines and channels rather than callbacks and futures.
这个里面netpoll应该就是blocking转变成none blocking的方法，不过不知道你用的那
个benchmark lib是不是支持了netpoll |
|
w***g
发帖数: 5958 | 41 用cpp可破。
：
：我上一個貼提到了golang兩大問題：GOGC和goroutine調度，今天開會同事又發現很多 |
|
g****t
发帖数: 31659 | 42 你说的这些都是很好的知识。但结论有些不靠谱。尤其是未来java的
Fiber赢goroutine.这个大部分其实是取决于资金，不是技术。 |
|
f*******t
发帖数: 7549 | 43 不知道你为什么一个劲地揪着某些运算的性能不放，眼光狭隘。我就不在另一个帖回复
了，意见统一写在这里。
* 写一个http web service，几十行代码没有额外dependency，编译成一个binary放到
所有环境中都能运行。C++行吗？
* 加第三方库一般go get一下就解决了。C++/java行吗？就我个人经验而谈，从github
下载的C++开源项目，几乎没一个能按照README里的步骤顺利编译的。
* 随便创建几百个goroutine，之间用channel通信，基本不用考虑性能问题，开发效率
极高。C++行吗？你在测试中发现的不容易解决的性能问题，都是极端条件下才会发生
的现象，绝大多数时候并不需要担心这点。
* Go才出现几年，没标准委员会很正常。大公司不敢用的说法完全没有逻辑。大公司有
百万行以上的代码，工具都是针对现有语言开发的，不可能直接替换成另一种语言，都
是先从一小群爱好者开始慢慢推广。这也是为什么Amazon等公司一直用Java，FB费好大
劲给PHP做HHVM。目前Go在中小型公司的新项目上很受欢迎，另外uber算大公司了吧，
很多backend se... 阅读全帖 |
|
w***g
发帖数: 5958 | 44 用cpp可破。
：
：我上一個貼提到了golang兩大問題：GOGC和goroutine調度，今天開會同事又發現很多 |
|
g****t
发帖数: 31659 | 45 你说的这些都是很好的知识。但结论有些不靠谱。尤其是未来java的
Fiber赢goroutine.这个大部分其实是取决于资金，不是技术。 |
|
f*******t
发帖数: 7549 | 46 不知道你为什么一个劲地揪着某些运算的性能不放，眼光狭隘。我就不在另一个帖回复
了，意见统一写在这里。
* 写一个http web service，几十行代码没有额外dependency，编译成一个binary放到
所有环境中都能运行。C++行吗？
* 加第三方库一般go get一下就解决了。C++/java行吗？就我个人经验而谈，从github
下载的C++开源项目，几乎没一个能按照README里的步骤顺利编译的。
* 随便创建几百个goroutine，之间用channel通信，基本不用考虑性能问题，开发效率
极高。C++行吗？你在测试中发现的不容易解决的性能问题，都是极端条件下才会发生
的现象，绝大多数时候并不需要担心这点。
* Go才出现几年，没标准委员会很正常。大公司不敢用的说法完全没有逻辑。大公司有
百万行以上的代码，工具都是针对现有语言开发的，不可能直接替换成另一种语言，都
是先从一小群爱好者开始慢慢推广。这也是为什么Amazon等公司一直用Java，FB费好大
劲给PHP做HHVM。目前Go在中小型公司的新项目上很受欢迎，另外uber算大公司了吧，
很多backend se... 阅读全帖 |
|
发帖数: 1 | 47 你是不是根本看不懂我最開始提到的goroutine sched問題？目前runtime 2根本不支持
NUMA，在G和M之間引入P完全是勉強提高性能的臨時解決方案，go關鍵字隱含多線程不
可控，性能低下在支持NUMA的新sched前完全無解。新sched概念早在2014年就提出了，
目前根本沒有實現，說明golang內部嚴重缺人，也是無解。go是二流語言沒跑。
DL/ML的核心庫都是cpp，py只不過是調用一下而已。
: 你讲的事实部分和你的结论完全没有关系。
: 比较的什么加拿大澳大利亚更是一比糊涂账。
: 多少年来除了你，没人拿golang和c plus比性能。
: 人的第一卖点是M:N scheduler
: 第二卖点不是语言，是易用性。
: 治地位
|
|
|
