Slide 1

Slide 1 text

Golang(*)と Erlang 鹿 @mizushika1 (*)正式名称は「Go」ですが、並べたときの響きの良さのために、 このスライドでは Golang と表記しています

Slide 2

Slide 2 text

名前は似てるけど、全然似てない Golang Erlang プログラミングモデル 手続き型 関数型 代入 何回でも 単一代入 コンパイル結果 バイナリ 中間言語 コンパイル結果 1ファイル moduleごとに別ファイル panic プロセス全体が死ぬ 軽量プロセスだけが死ぬ

Slide 3

Slide 3 text

スレッドを起動して Hello World の例 -module(hello). -export([start/0, printer/0]). start() -> Pid = spawn(fun printer/0), Pid ! "Hello World~n". printer() -> receive msg -> io:fwrite(msg) end. package main import "fmt" func main() { ch := make(chan string) go printer(ch) ch <- "Hello World" <-ch } func printer(ch chan string) { msg := <-ch fmt.Println(msg) close(ch) }

Slide 4

Slide 4 text

runtime では似ている部分もある • スレッドモデルはどちらも M:N • Golang で言う goroutine • Erlang で言う軽量プロセス • GC • ある • Golang は Mark and Sweep 方式 • Erlang は 世代別 GC も採用 • スレッド間の共有方法 • 変数をキュー(チャンネル)にコピーして通信 • Share memory by communication

Slide 5

Slide 5 text

runtime で似ているけど違う部分を紹介 • スレッドモデル • GC • スレッド間の共有方法

Slide 6

Slide 6 text

スレッドモデル • M:N = OSスレッド:ランタイムのスレッド • スケジューラスレッドがOSスレッドとして存在 • ランタイムのスレッドを順番に実行していく • スケジューラが空いたら他のスケジューラから奪ったりもする • Go で言う G, P, M の話 • 優先度設定は限定的 • Linuxカーネルだと、SCHED_** とか nice 値とかが指定できるが、 • Golang は優先度設定一切無し • Erlang は実質2レベルあり、ランキューが2本だけある • Golang は goroutine に名前を付けられない • 名前が無いので、外から状態を把握したり止めたりできない • Erlang は VM で動くのでリモートから接続してトレースができる

Slide 7

Slide 7 text

GC • Garbage Collector • プログラマがヒープメモリの開放を気にしなくて良い仕組み • 通常の人類には必須の機能 • Golang はプロセス全体で GC をかける • Mark and Sweep という昔ながらの方式 • Mark のときに STW (Stop-the-World) が発生して、全goroutineが止まる • Erlangは軽量プロセス(runtimeスレッド)ごとにGCをかける • 他の軽量プロセスは影響を受けない • グローバル変数やポインタが無いからできる技 • 実行タイミングは「関数呼び出しの回数」

Slide 8

Slide 8 text

スレッド間の共有方法 • チャンネル or メッセージキューを推奨している • データがコピーして格納されるので shared nothing にできる • Golang • チャンネルは自分で作る • 段数があり、それを超える write はブロックされる • close 済みのチャンネルに write すると panic になる • Erlang • 軽量プロセスを作ると自動でそれ用のメッセージキューも作られる • 段数は無限で、メモリの許す限り write できる • 存在しない相手に write してもエラーにならない • 1プロセス1キューなので、fan-out 構造は工夫が必要

Slide 9

Slide 9 text

まとめ • Golang と Erlang の、 似てないようで似てるようでやっぱり違う点の紹介をした • どちらも M:N スレッドモデルを採用しており、 設計思想が共有できる点が多い(かも) • M:N スレッドモデルは今後広まっていきそう • Ruby の Ractor とか • Java の VirtualThread とか • 個人的感想 • Golang の GC も大量の goroutine 利用に適したものになってほしい • 世代別 GC を熱望している