作者oopFoo (3d)
看板Soft_Job
標題Re: [請益] 為什麼 Go 會紅？
時間Wed Apr 4 10:45:34 2018
※ 引述《LinuxKernel (Linus Torvalds)》之銘言：
: 不敢說會寫，只能說略懂，以下簡單分享。
: 先說覺得好的地方
: 1. 對 non-blocking 的封裝
: 大家都知道在 C/C++ 底下要寫出高併發性能的 server 很多細節是很麻煩的
: 你可能說寫 server 不就開個 socket 搭配 fork 多麼直觀
: 但現實是要達到好的性能就需要 select、epoll、kqueue 甚至 thread pool 之類的東西
: 但 non-blocking 的世界畢竟不是那麼直觀
: Go 強的地方就在於他讓你用很直觀的 blocking 寫法
: 一個 client 進來你也就像 fork 一樣給他開個 goroutine
: 但實際上它底層 runtime 就是用 epoll/kqueue 幫你做掉
: 也幫你做這些 lightweight thread 的 scheduling
: 當然 C/C++ 的世界也有類似的 library 可以辦到，像是 Boost.Fiber
: 但 Go 裡面用 goroutine 搭配 channel 感覺就是優雅了些
: 不過 goroutine 還是有可能踩到坑的
: 例如 goroutine 就永遠卡在那邊，這點可以去了解一下它 scheduling 的實作
goroutine應該說是preemptible blocking. epoll是io的部份，跟goroutine
無關。
Boost.fiber 是coroutine. 打個比喻就是win3.1的 cooperative multitasking.
goroutine 是 win95 的preemptive multitasking.完全不同等級的概念。
goroutine應該是模仿Erlang的process. channel就是message passing.
簡單來講golang就是better c + gc + concurrency.
goroutine 其實是golang的最重要功能。寫過Multithread的人都知道，
盡量不要share memory. Lock carfully(avoid 2 locks if possible),
wait as little as possible.
Multithread是very HARD(tm)的，bug非常難找，真的極少人寫的好。
寫過Erlang的人都知道, concurrency is SIMPLE. golang也是
同樣的.
為什麼goroutine is SIMPLE, multithread is HARD. 重點就是channel,
(Message Passing). 只要不要share data. concurrency就簡單了。
我們都知道Moore's Law is dead. 以後multi-core只會越來越多，
cpu的frequency不會增加太多。Concurrency programming只會越來越重要，
Erlang證明它的concurrency programming model work. Golang 是
google想辦法把concurrency programming 帶到大家能用的語言上來。
我覺得golang用的人會越來越多。它其實是真的c的後繼語言。
大大推薦。
-補充一下---------
除了FreeBSD的phk大神，大家的共識是1 thread per io connection is bad
for performance. goroutine + event polling是很棒的組合。
golang 不是fully preemptive. function call 的地方是golang
主要的preempt point. 所以如果你有tight loop，沒有function call,
需要被preempt的話請加runtime.Gosched()在中間。其實tight loop
不被preempt是對performance很好的。
比較好的解釋在這。
https://github.com/golang/go/issues/11462
想了解golang scheduler請google.我的語文能力實在不是很好。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.146.79
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1522809937.A.CBA.html
1F：→ dreamnook: multi thread真的很頭痛 碰到表皮就不敢再深入xD 04/04 10:56
2F：→ pokman: 那rust呢? 04/04 13:13
3F：推 foodordertw: 你沒講到golang的scheduler的核心 04/04 13:50
4F：→ foodordertw: 你應該要講的是multithread並沒有解決io blocking 04/04 13:51
5F：→ foodordertw: goroutine則是原生的解決lock/io blocking 04/04 13:52
6F：推 rodion: 聽起來跟python/js的async-io差不多? 04/04 14:55
8F：→ remmurds: golang 所有的缺點都整理在這裡了 04/04 15:16
9F：推 MineCola: 看到樓上連結裡面某一條戳中笑點：un-googlable name 04/04 17:49
10F：→ ssadow: 寫multi thread超好玩的 怎麼大家都不喜歡 04/04 19:46
11F：推 ssadow: 而且goroutine不就是thread pool嗎 還是multi thread啊 04/04 19:53
12F：推 soheadsome: gorountine是有調教過的thread 他的stack是可以動態調 04/04 20:12
13F：→ soheadsome: 整 04/04 20:12
14F：→ soheadsome: 如果是普通thread 他的stack就跟普通function差不多 04/04 20:12
15F：→ soheadsome: 頂多多了local storage 04/04 20:12
16F：推 alex70266: 寫multi thread 很好玩啊，debug 的時候就不好玩了XD 04/04 20:23
17F：推 snaketsai: goroutine會被preempt schedule ?? 04/05 06:30
18F：推 snaketsai: 剛剛看了runtime/proc.go的sysmon跟retake() ... 04/05 06:44
19F：→ snaketsai: 這作法拿來講preemption個人覺得實在有點微妙... 04/05 06:45
※ 編輯: oopFoo (36.231.144.2), 04/05/2018 10:40:21
20F：→ badyy: 他的preempt schedule 是coopertive的 04/05 16:44
不是，而是有限定的點，如function call. 這時preempt不用save一堆data.
go的design概念是清楚，簡單，有效率。syntactic sugar都不要。
21F：推 PeacockLiu: 曾經用C寫了multithread，debug了半個月..... 04/06 00:40
握手。寫久了，才有感覺如何debug.
※ 編輯: oopFoo (59.115.100.33), 04/07/2018 20:41:00
22F：推 qmailtw: 硬體變快了，大家覺的犧牲ㄧ點效能來換工作效率 04/12 12:36
23F：推 qmailtw: 看了這麼長的文章，請問goroutine 和 coroutine 有什麼 04/12 12:39
24F：→ qmailtw: 不同？ 04/12 12:39
coroutine你要自己yield 讓其他function跑. gorouine會被preempt.
※ 編輯: oopFoo (61.230.104.167), 04/12/2018 21:32:34