Go language part 5

**デフォルトの名無しさん** · 2022/02/27(日) 07:43:20.04

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
https://golang.org

公式ドキュメント
https://golang.org/doc/

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

※前スレ
Go language part 4
https://mevius.5ch.net/test/read.cgi/tech/1605467680/

**デフォルトの名無しさん** · 2022/02/27(日) 07:45:13.76

公式
https://golang.org

公式ドキュメント
https://golang.org/doc/

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

**デフォルトの名無しさん** · 2022/02/27(日) 07:46:00.05

あ、これ2のテンプレじゃないのか

**デフォルトの名無しさん** · 2022/02/27(日) 08:59:11.36

>>992（前スレ）
読んだ。で、やっぱり奇妙なんだけど、多分オーバーヘッドはないと思うよ。

一般的にはガードページなんて必要なくて、コピーオンライトと同じで、
ページ境界を跨いだ場合はハードウェアで検出出来るから、まず普通はそれを使う。
この場合は自前でのチェックは必要ない（ソフトウェアには必要ない）ので、オーバーヘッドはない。
だからGoの当初の初期スタックサイズが4kだったのは非常に納得出来た。ここまではいい。

これを小さくするならハードウェアのサポート無しになるから当然自前でチェックするしかないが、この場合、
・2kも大きすぎ。自分でやるならRustのように64Bytesからとか、4kに拘らず凄く小さいスタックサイズから可能だし、普通はそうする。
・そもそも必要スタックサイズを予見出来ない。というか出来るならコンパイル時に確定的に割り当てれば済んでる。
であって、Rustの実装は非常に納得出来るのだけど、Goのは若干意味不明なんだよ。
（ただまあ何かしら理由はあると思うけど）

2kとかいう、4kに拘ったサイズになってるんだから、多分何かしらハードウェアのサポートを受けてて、
自前ではスタックサイズのチェックはしてないと思うよ。（つまりオーバーヘッドがない）
可能性があるのは、2kをはみ出る時には4k境界を跨ぐようにして（つまりまずは上側を割り当てる）
はみ出た時に2kずらしていくとかだけど。
ただこの方式の場合、初期アロケーションだけは4kでされてしまうので、957のベンチでは40MB越えないとおかしくて、矛盾してる。
だから正直よく分からないが、
多分オーバーヘッドのない方式で実装してて、だから2kとかいう中途半端な巨大サイズになってるのではないかと思う。

**デフォルトの名無しさん** · 2022/02/27(日) 09:14:34.62

>>998（前スレ)
分かりやすい説明ありがとう。発想は面白いね。
確かにその方式だと死蔵メモリは最小限に留められ、Goの問題は解決されてるはずだね。

>>986(前スレ)
998の通りだと、外部からのプリエンプションではなく、
コルーチンが処理を(自発的に)返してくるから、その単位での切換だろう。
まあこれでも現実的には問題ない気はする。

**デフォルトの名無しさん** · 2022/02/27(日) 09:39:32.40

ちなみに前スレ1000と同じく、1桁少ない1000スレッドで同じPCでgoを測ると
$ go version
go version go1.13.8 linux/amd64
$ go build main.go && ./t ./main
real 12.02s
user 0.91s
sys 0.22s
rss 3808k
$
やはり4Mを超えない(rssでいいの？とは思うけど)

**デフォルトの名無しさん** · 2022/02/27(日) 10:24:28.50

推奨NGWord
正規表現で「.{50}」を設定
長文を排除できます

**デフォルトの名無しさん** · 2022/02/27(日) 14:25:03.95

>>992（前スレ）
訂正。他も色々漁って、やっぱりオーバーヘッドはあると思えてきた。
ただし多分0～4cycle/関数呼び出し程度だね。

主に読んだのは以下とか。
https://github.com/tinygo-org/tinygo/issues/2000
https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast
https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite

・当初は8kだったが、もっとでかくしろという要求が多かった
・1kに出来てる実装もあるが、こける事もあるから2kがデフォになってる
・同じ図が説明に使われてて、どうやら最初からこの方針らしい

本人達が「チェックしてる」って言うんだからやっぱりそうなんだろう。
一番ありそうな実装は、呼ばれた関数側で最初にチェックする方法で、
つまりローカル変数をスタックに確保するためにスタックポインタからサイズを引く時にチェックする。
これだと、 mov, (sub,) xor, and, jne の追加4命令で(subはチェック無しでも必要）
主にINTパイプで最悪で4cycle、大体の場合はこのあとのLSパイプ(スタック上へのレジスタ待避）に隠れて見えなくなるのではないかと。
だから関数呼び出し毎に0～4cycのペナルティになる。
ただし、速くなる事はないし、隠れると言っても演算リソースは消費するので、
ハイパースレッディングの場合に相手側のCPUの速度が落ちるのは否めないが。

2k以下にもやれば出来るのだろうけど、やる気がないだけだね。
だから2kで問題なら、コンパイラをいじれば何とかなるのだろうけど、
そこまでやるくらいならRustの方が断然いいね。(後発だから当たり前だけど)

**デフォルトの名無しさん** · 2022/02/27(日) 15:40:03.99

関数呼び出しのオーバーヘッドだけど、高階関数らしい高階関数も無いしそういうややこしいことはジェネレーター使う文化だと思ってるな。Genericsが本流になってきたらどうする気だろうもも思ってる。
なお、比較する関数程度の関数はインライン化される。
https://github.com/golang/go/wiki/CompilerOptimizations

**デフォルトの名無しさん** · 2022/02/27(日) 16:13:39.08

>>9
> 高階関数らしい高階関数も無いし
いや高階関数は普通に出来る。
https://go-tour-jp.appspot.com/moretypes/25
標準やフレームワークにそれを活用する文化がない、という主張なら俺はその辺は知らん。

**デフォルトの名無しさん** · 2022/02/27(日) 16:48:28.74

>>10
できるけど、Goではやらんのよ。
凄く纏まってる。
https://zenn.dev/nobonobo/articles/e0af4e8afc6c38b42ae1

**デフォルトの名無しさん** · 2022/02/27(日) 17:20:40.92

>>6
自己レスです。
Goは1.4からamd64だとスタック2k
https://github.com/golang/go/issues/7514
今回試した1.13.8だと当該コードがCからgoに変わったりして跡形もなかったが、_StackMin = 2048はそのままだった
https://github.com/golang/go/blob/go1.13.8/src/runtime/stack.go
つまり2Mであれば残り1.8Mということで矛盾はない

**デフォルトの名無しさん** · 2022/02/27(日) 17:32:40.97

>>12
1000個立ち上げなんて1桁減らして測定してるからメモリ使用量がわかりにくいような
素直に1万個と10万個で調べて差を見れば1個あたりがはっきりするような

**デフォルトの名無しさん** · 2022/02/27(日) 17:44:54.95

>>13
時間かかるのが嫌で減らしただけです。。。

ちなみに後ろにウェイト入れて、cat /proc/[pid]/statusした結果
VmHWM: 3296 kB
VmRSS: 3296 kB
VmSwap: 0 kB
なので、rssだけでいいと思います。

**デフォルトの名無しさん** · 2022/02/27(日) 20:47:56.30

>>11
> 結局のところ素直にforループを書くのがGoには適していて、
> 汎用の型に適用可能な高階関数を実装しようとするのはミスマッチ
これってforEachを実装しようとするのが間違いって事？
或いはmapに高階関数を食わせるのを嫌ってるのか？
いずれにしても、やりたきゃやれよ、だと思うが。

オレオレコーディングルール集だが、全般的に現状肯定的なので、
目指すコーディングではなく、今のGoコンパイラ/ランタイム向けのTips集になってる。
これがどれくらい賛同されるのか不明だけど、革新/改革派からは気に入らない内容だろうよ。
Python出身のようだから、この辺C系の「何でもやっていいけど、結果責任は取れ」文化とは根本的に違うのだろう。
一種類のコードになる事を良しとしてる。

> goroutiineのスケジューラはもちろん依頼処理コストが大きい場合をフォーカスしてチューニングされています。
> ひとつのgoroutineがCPUを占有しすぎないように分散してくれる仕組みがありますが、
> 小さすぎる処理コストをまとめるのは実装者の責任で行わなくてはなりません。
> 小さすぎる処理を頻繁に繰り返すだけであればシングルスレッドの方が速い結果が出るのは当たり前なのです。
これとか、1,000,000goroutine全否定だよね。俺は
Go信者：1,000,000goroutineでも軽いし速い←嘘つくな
GoUser：遅いけど1,000,000goroutineで書きたいんだよ←うむ、遅いと認めるならよろしい。しかし速くなる努力はしたまえ

> Goはデバッガビリティのために末尾再帰最適化をあえて実装していません。
いや怠慢でしかないだろ。再帰がデバッグしづらいとか聞いた事無いわ。

ちな、
> 自作ライブラリの利用方法をメソッドチェインで作ろうとする
考えた事無かったけど、try-catchのメリットってメソッドチェインできることか。
なるほどだからろくにメソッドチェイン出来ないPHPだと何ら意義を感じ取れなかったわけだ、納得。

**デフォルトの名無しさん** · 2022/02/27(日) 21:18:41.64

>>15
Goと同じくtry-catchの無いRustはメソッドチェーンが基本の言語だぜ
関数の返り値が基本的にenumとなってエラーも正常値もメソッドチェーンで処理できるようになってる

**デフォルトの名無しさん** · 2022/02/27(日) 21:41:54.35

>>14
もしかして俺が前スレ962で単純に40MB足してたのが気になってたのなら申し訳ない。
あれは足しすぎだった。RSSの意味は以下。
https://stackoverflow.com/questions/7880784/what-is-rss-and-vsz-in-linux-memory-management
十分なメモリがある状況で普通に実行させた直後（スワップされてない状況）なら、RSSで問題ない。（はず）

以下は前スレ992内にある図だが
https://commons.wikimedia.org/wiki/File:Table_of_x86_Registers_svg.svg
これ全部を待避するのに1kB程度かかるらしく（真面目に数えれば正確な数値は出せるが、やる気無し）
この分をOS側が待避するので、単純に言えばスレッド数*1kB程OS側のメモリを食ってる。
これがgoroutineだと必要ない(Goランタイム管轄で待避で、RSSに計上されてる）ので文句付けられてる。

だから公平に見るなら、goroutineはRSSそのままで良く、OSのthreadを使うならスレッド数*1KB程度追加かと。
(40MBはスレッド数*4kBにしてるので、多すぎ。
アクセスのない、単なる待避領域なので、ページ単位である必要はない。）

そして関数呼び出しのオーバーヘッドについてはそこにモロに書いてあるな。(GitHub上ソースの17行目～60行目)
0～4Cycleのオーバーヘッドになる。
方式としては、スタックの底に96Bytes(=40+56)の領域があらかじめ確保してあって、
これらはメモリが足りない時に呼ばれるdeferproc()とmorestack()に必要なスタックサイズなのだが、
逆に言えば96Bytes以下のスタックしか使わない関数ならスタックポインタがそこを越えてなければ問題ないわけで、
以下チェックを通してる。(guardがスタック満タン-96Bytesのアドレスを示してる)
> CMPQ guard, SP
> JHI 3(PC)
> MOVQ m->morearg, $(argsize << 32)
> CALL morestack(SB)
まあスタック増加がなければINT/BR/NOP/NOPなので、オーバーヘッドは通常1か2Cycleじゃないかと思うけども。

**デフォルトの名無しさん** · 2022/02/27(日) 22:00:44.12

>>12
ちなみにコードが素晴らしくメンテされてれば、

_StackMin = 1024

にするだけで、スタックサイズが1kBになるような気もします。

**デフォルトの名無しさん** · 2022/02/27(日) 22:21:07.92

>>15
そもそも革新、改革がしたいならGoじゃない言語でやれば良いんよ。ひたすらに後方互換を維持してんだし。

1種類のコードになることを良しとしてるのは当初からよ。そうでなければ、gofmtが一切のオプションを持たないはずがない。

多数のgoroutine全否定ではなかろうに。
遅いように書いたgoroutineは遅いとしか言ってない。

ちなみに末尾再起はgdbなんかでデバッグしてるとデバッガビリティ低いと思うよ。俺もそう思う。
普通はデバッグビルドだと末尾再起無効では？cppなんかでも。

**デフォルトの名無しさん** · 2022/02/27(日) 23:03:35.02

>>19
いやあれは「べからず集」なのだから否定だと思うぞ。
まあいいが。

> 普通はデバッグビルドだと末尾再起無効では？cppなんかでも。
そもそもデバッグビルドなら『全ての』最適化は無効だ。そしてその状態で全てのデバッグを行う。
それでリリースビルドでは一発で動く、というかデバッグしないのが基本だ。
（同じ出力を生成する事だけを確認する）
「デバッグビルドでは動くのですが、リリースビルドでは動きません。これってコンパイラのバグですよね？」は初心者あるあるだが、死ねでいい。

リリースビルドでデバッグすると、ブレークポイントも当たらなかったりで、ろくな事はない。
深い再帰とかが例えば演算系なら、毎回再帰前にprintfで全部の値をログに出し、
リリースビルドで動かした出力とdiffを取り、完全一致になってなければバグとして、あくまでデバッグビルドでデバッグする。
そのファイルが数GBになって、普通のdiffでは無理になったら、完全一致専用のdiffを手作りする。
実は浮動小数点だと完全一致はしないが、それなら誤差範囲を指定したスクリプトを書いて比較だ。
というのが俺流で、つまり別の戦術で回避済みだから、
リリースビルドでどんな最適化がされてても、コンパイラがバグってない限り関係ないね。
そしてコンパイラなんてバグってない。俺は誰でも書いてるようなコードしか書かないし。

それ、リリースビルドでデバッグしてる事が問題なのでは？
(まあ気持ちは分かるけども。俺も最初はそうしてて、駄目だったので上記になってる)

**デフォルトの名無しさん** · 2022/02/28(月) 00:19:43.12

>>16
以下9章だけは読んだ。
https://doc.rust-jp.rs/book-ja/ch09-00-error-handling.html

俺はこれで全く問題ないけども、try-catch派は多分文句を言うような気はする。
あと、これは型をResultで統一すればどの言語でも出来るので、言語と言うよりはフレームワークの設計なのだろう。
(フレームワークを跨いでも統一してる方がいいから、言語としてこれだ！というのは意味はあるが）

ただ、エラー処理って方式が統一されてる事が重要だから、今更ではある。
そんな事よりGoはRustのasyncをパクるべきだろう。
コルーチンみたいな名前で実はスレッドではないか！という批判が無くなる。
実は当初goroutineと名付けた時に欲しかったのは、これだったんじゃね？とも思う。
yieldさえあればあっさり出来るのだろうけど。(無くても無理矢理やれば出来るが）
つか、無い理由は何なんですかねこれ？

**デフォルトの名無しさん** · 2022/02/28(月) 00:24:03.28

template feature実装したgolangのstable公開3月だっけか
作者がc++嫌いだからのgoなのに偉大なるc++への一歩を踏み出そうとしてるのは皮肉な事だが
ライブラリ等もかなり便利になるのではないかとかなり楽しみ(´・ω・｀)

**デフォルトの名無しさん** · 2022/02/28(月) 00:35:47.82

>>17 >18
むしろ前スレ957のベンチ(元記事)では、

"In particular, 10k threads with default stack sizes need about 40mb of page tables to map virtual memory."

と訂正しているのだから、前スレ962の計算で40MB足してるのはおかしくない。
ただ、>>4で再び「957のベンチでは40MB越えないとおかしくて、矛盾してる」と言ってるのが、普通に考えるとRSS対象なので、スレッド数を10kから1kにした俺版でも前スレ1000のC++版との対比する意味もあり、改めてgo版の結果を同じ条件で出した(>>6)だけ。
結論は同様にRSSは4MBを超えないので、仮想メモリ側にあるという元記事の主張で正しいようにも見える。
しかし、go処理系が不明な元記事と違い、自分でやっていれば実際バージョンは分かるわけで、そこが分かればスタックサイズはソースを見れば一目瞭然ということで経緯と一緒に調べたのが、>>12で結論としては2Kだったということ。
すると元記事の推測と自分の計測結果には矛盾があり、2KBが仮想メモリにあるかどうかを明確にする必要が出たため、>>14で/procに頼った。
結論は仮想メモリ(swap)使ってないよって話だったので、少なくとも俺の環境では元記事とは違いRSSでいいという結論が出て、>12の結論とも整合が取れた。

別にdistro標準(ubuntu 20.04)のgo処理系を使っているので、ソースを引っ張ってくれば簡単に１KBに変更は出来るか確認出来ると思うけど、面倒なのでそこまではしない。