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でいいの？とは思うけど)