781(2): デフォルトの名無しさん [sage] 2020/11/01(日) 08:14:15 ID:0aiHjqpe(1/12) AAS
>>780
> goのスタックフレームつまり自動変数も他の言語とは隔絶
どこが？サイズだけならCは調整出来たと思ったけど

> そのため、数百万のgoroutineを作成できる
それは既に結論は出てる。
以下ブログ、俺が読んだ時とはだいぶ趣が異なるが、（当時は確か初期サイズ4KBだったはず）
外部ﾘﾝｸ:github.com
要は2KBでも十分大きすぎて、Nodeの方が断然まし、ってことになってる。

これは当たり前で、Linuxのkernel領域でのスタックサイズが128Bだったか256Bかに制限されているらしいから、
その気になればLinuxは256B/threadでスレッドを起動出来る。
そしてNodeはシングルスレッドだからスタック領域が余すところなく全部消費される。
これはGoではどうやっても出来ないことだ。
というよりJSのシングルスレッドアーキテクチャは最初からこのc10k問題解決を主眼にしてる。
だからその領域ではそれ用に作られたJSに勝てるはずもなく、実際そうだった、というだけ。

goroutineのサイズをケチってどうこう、って作戦は究極にはJSのシングルスレッドアーキテクチャに行き着く。
だからその方向ではNodeには勝てないのは仕様だよ。
そうじゃなくて、言語サポートがあるからスレッドがお気楽に使え、それがgoroutineです！って方が順当で、
実際そのブログの作者も喜んで使ってみたが、思ってたと違う、、、というのがそのブログだよ。

> そのため、数百万のgoroutineを作成できる
数百万のthreadなんて実際あり得ないし、管理も出来ない。
そこをgoroutineならお気楽に生成/消滅出来るので、これまで「面倒/管理が難しい」等でthread起動しなかったところを、
「これは別スレッドでも動く」というだけの理由でお気楽にすべてgoroutineで切り離して行けば一見超並列出来そうに見える。
ただ、実際それをやったらそこで遭遇している問題、つまりgoroutineは思っているほど軽くない、に遭遇してしまう。
現実的にはthreadなんて論理CPU数の2倍程度あればCPU処理だけなら埋まってしまうからそれ以上起動しても意味がない。
I/Oで引っかかった時のスタックサイズをケチりたいのなら、
JSのように非同期でシングルスレッドにする方が原理的に上だし、実際そうだった、というのがそのブログだ。