Go language part 5

[過去ﾛｸﾞ] Go language part 5 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

1: デフォルトの名無しさん [sage] 2022/02/27(日) 07:43:20.04 ID:uWHjNeVw(1/3) AAS
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
https://golang.org

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

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

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

※前スレ
Go language part 4
2chｽﾚ:tech

2: デフォルトの名無しさん [sage] 2022/02/27(日) 07:45:13.76 ID:uWHjNeVw(2/3) AAS
公式
https://golang.org

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

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

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

3: デフォルトの名無しさん [sage] 2022/02/27(日) 07:46:00.05 ID:uWHjNeVw(3/3) AAS
あ、これ2のテンプレじゃないのか

4(1): デフォルトの名無しさん [sage] 2022/02/27(日) 08:59:11.36 ID:PVy06kKY(1/8) AAS
>>992（前スレ）
読んだ。で、やっぱり奇妙なんだけど、多分オーバーヘッドはないと思うよ。

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

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

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

5: デフォルトの名無しさん [sage] 2022/02/27(日) 09:14:34.62 ID:PVy06kKY(2/8) AAS
>>998（前スレ)
分かりやすい説明ありがとう。発想は面白いね。
確かにその方式だと死蔵メモリは最小限に留められ、Goの問題は解決されてるはずだね。

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

6(2): デフォルトの名無しさん [sage] 2022/02/27(日) 09:39:32.40 ID:+yReYAPt(1/3) AAS
ちなみに前スレ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でいいの？とは思うけど)

7: デフォルトの名無しさん [sage] 2022/02/27(日) 10:24:28.50 ID:c+lx/lLr(1) AAS
推奨NGWord
正規表現で「.{50}」を設定
長文を排除できます

8: デフォルトの名無しさん [sage] 2022/02/27(日) 14:25:03.95 ID:PVy06kKY(3/8) AAS
>>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の方が断然いいね。(後発だから当たり前だけど)

9(1): デフォルトの名無しさん [sage] 2022/02/27(日) 15:40:03.99 ID:F0hGMDSU(1/3) AAS
関数呼び出しのオーバーヘッドだけど、高階関数らしい高階関数も無いしそういうややこしいことはジェネレーター使う文化だと思ってるな。Genericsが本流になってきたらどうする気だろうもも思ってる。
なお、比較する関数程度の関数はインライン化される。
https://github.com/golang/go/wiki/CompilerOptimizations

10(1): デフォルトの名無しさん [sage] 2022/02/27(日) 16:13:39.08 ID:PVy06kKY(4/8) AAS
>>9
> 高階関数らしい高階関数も無いし
いや高階関数は普通に出来る。
https://go-tour-jp.appspot.com/moretypes/25
標準やフレームワークにそれを活用する文化がない、という主張なら俺はその辺は知らん。

11(1): デフォルトの名無しさん [sage] 2022/02/27(日) 16:48:28.74 ID:F0hGMDSU(2/3) AAS
>>10
できるけど、Goではやらんのよ。
凄く纏まってる。
https://zenn.dev/nobonobo/articles/e0af4e8afc6c38b42ae1

12(3): デフォルトの名無しさん [sage] 2022/02/27(日) 17:20:40.92 ID:+yReYAPt(2/3) AAS
>>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ということで矛盾はない

13(1): デフォルトの名無しさん [sage] 2022/02/27(日) 17:32:40.97 ID:Xl3wWN+O(1/2) AAS
>>12
1000個立ち上げなんて1桁減らして測定してるからメモリ使用量がわかりにくいような
素直に1万個と10万個で調べて差を見れば1個あたりがはっきりするような

14(2): デフォルトの名無しさん [sage] 2022/02/27(日) 17:44:54.95 ID:+yReYAPt(3/3) AAS
>>13
時間かかるのが嫌で減らしただけです。。。

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

15(2): デフォルトの名無しさん [sage] 2022/02/27(日) 20:47:56.30 ID:PVy06kKY(5/8) AAS
>>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だと何ら意義を感じ取れなかったわけだ、納得。

16(1): デフォルトの名無しさん [sage] 2022/02/27(日) 21:18:41.64 ID:Xl3wWN+O(2/2) AAS
>>15
Goと同じくtry-catchの無いRustはメソッドチェーンが基本の言語だぜ
関数の返り値が基本的にenumとなってエラーも正常値もメソッドチェーンで処理できるようになってる

17(1): デフォルトの名無しさん [sage] 2022/02/27(日) 21:41:54.35 ID:PVy06kKY(6/8) AAS
>>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じゃないかと思うけども。

18(1): デフォルトの名無しさん [sage] 2022/02/27(日) 22:00:44.12 ID:PVy06kKY(7/8) AAS
>>12
ちなみにコードが素晴らしくメンテされてれば、

_StackMin = 1024

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

19(1): デフォルトの名無しさん [sage] 2022/02/27(日) 22:21:07.92 ID:F0hGMDSU(3/3) AAS
>>15
そもそも革新、改革がしたいならGoじゃない言語でやれば良いんよ。ひたすらに後方互換を維持してんだし。

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

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

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

20: デフォルトの名無しさん [sage] 2022/02/27(日) 23:03:35.02 ID:PVy06kKY(8/8) AAS
>>19
いやあれは「べからず集」なのだから否定だと思うぞ。
まあいいが。

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

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

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

21(1): デフォルトの名無しさん [sage] 2022/02/28(月) 00:19:43.12 ID:BEDnUIJv(1/3) AAS
>>16
以下9章だけは読んだ。
https://doc.rust-jp.rs/book-ja/ch09-00-error-handling.html

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

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

22: デフォルトの名無しさん [] 2022/02/28(月) 00:24:03.28 ID:3SjSMxvC(1) AAS
template feature実装したgolangのstable公開3月だっけか
作者がc++嫌いだからのgoなのに偉大なるc++への一歩を踏み出そうとしてるのは皮肉な事だが
ライブラリ等もかなり便利になるのではないかとかなり楽しみ(´・ω・｀)

23(1): デフォルトの名無しさん [sage] 2022/02/28(月) 00:35:47.82 ID:EeqSDih1(1/3) AAS
>>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に変更は出来るか確認出来ると思うけど、面倒なのでそこまではしない。

24: デフォルトの名無しさん [sage] 2022/02/28(月) 01:17:28.02 ID:qPXeLVFX(1/5) AAS
反論はそこだけ？

25: デフォルトの名無しさん [sage] 2022/02/28(月) 01:18:12.57 ID:qPXeLVFX(2/5) AAS
>>21
これだけ指摘されて、まだスレッドだと思ってるのは少ないのでは？

26: デフォルトの名無しさん [sage] 2022/02/28(月) 01:33:25.66 ID:EeqSDih1(2/3) AAS
一般には
coroutine + thread -> goroutine, async/await
という認識の人が多数だと思う

27(3): デフォルトの名無しさん [sage] 2022/02/28(月) 14:52:59.85 ID:xNWA4laA(1/2) AAS
このasyncおじさんは何も分かってないと思う・・・
nodeでasync/awaitが通るのは、シングルスレッドですべてのメモリーが一緒のためで、Goのようにgoroutineで実際に
割り当てられているCPUやスレッドが分からないようにあえてしている言語で、asyncなんて導入するわけない。
async/awaitがある言語でそれがThreadを混ぜ込める言語もあるが、それだってI/Oをブロックしている処理の終わりに
ただ同じスレッドを再割り当てするだけ。スレッド境界を越えてメモリーコピーあるいは同期なんてしてたら破綻する
async/awaitのもとになるような、多くのスクリプト言語でyield、つまりジェネレータの重要なユースケースは、I/Oブロックの
待ちで違う処理を行うことだが、それはI/Oバウンドな待ちでしか処理が切り替わらないことを意味する。

28(2): デフォルトの名無しさん [sage] 2022/02/28(月) 15:07:48.45 ID:xNWA4laA(2/2) AAS
async/await,そしてyieldが唯一優れているのは、Goでいうchannelのclose処理が要らないことだけ。

他は全部劣っているし、CPUバウンドでは切り替わらないし、async/awaitなんていうキーワードがプログラミングがしやすいか
といえば全然そんなことは無く、async/awaitで書かれたコードと、完全同期の一直線で進むプログラミングでは、互換性に
乏しいライブラリばかりができる。async前提で作られたコードは同期プログラミングでは使えなかったり、同期プログラミングで
作られたライブラリは処理がI/O待ちになっても、asyncが入っていないため非同期では効率が劣る。
決定的には、並列性が大きく劣っている事は言うまでもない。
もちろんこれは速度などという効率の指標ではなく、理論上はCPUコア数=スレッド数で、他はすべて非同期にしたほうが
速いのは、何も考えずとも当たり前。（無駄なコンテキストスイッチや同期処理が発生しないから）

「当初欲しかったのはこれじゃね？」なんていう超ド素人の勝手な想像と思い込み、調べもしない無知でこんなところで
ダベっていてもまったく意味ない。
Go言語の作者の一人であるRob Pike氏が「OSスレッドではなく、ユーザー空間スレッド」「メモリ使用量がOSスレッドに
対して、500倍ほど有利」「OSコンテキストスイッチよりも有利」といい、Cの作者として有名な、Kenneth Thompsonが
「C++が嫌いだということで意気投合」「いかなる理由があっても言語にゴミを入れません」と語っているように
I/O非同期なんていう半端な偽物は、眼中にない中で、まさしくasync/awaitは１つの利点だけの無用な長物であり
プログラミングを複雑にするだけで、つい最近まで総称型さえも、強烈に拒んでいた保守的で長く使えるよう言語仕様を
守り続ける言語に入るわけない。
そんなにやりたかったらお前がforkしてやれ、じゃなきゃGithubでIssueでも投下してこい。それすら出来ないなら
お前は不当に他言語を卑下してる卑怯者だぜ。どうせボコボコにされる

29: デフォルトの名無しさん [sage] 2022/02/28(月) 15:52:51.20 ID:BKvqTAvD(1) AAS
>>27
流石にその理解はヤバいぞ
asyncおじさんをバカにしてる場合じゃない

30: デフォルトの名無しさん [sage] 2022/02/28(月) 19:32:24.79 ID:7SSxP2tw(1/2) AAS
>>27
その主張は間違い
例えば現実にある反例として
RustでもGoと同じくワークスティーリングをするM:Nモデルで非同期タスクが動きasync/awaitが導入されている

>>28
あまりにも偏った思い込みと勘違いが激しすぎる

31(1): デフォルトの名無しさん [sage] 2022/02/28(月) 19:53:28.26 ID:qPXeLVFX(3/5) AAS
Rustでもできる、は聞き飽きたんだが、Rust話がしたいのか？
Rustの話はRustスレで聞きたいんだが、とうしてRustスレではN:Mグリーンスレッドの優位性の話してないの？

実際Rustでtokioをランタイムとして使ってみたけど、思ったより書き味が良くないしな。
Goのサクッと書いてサクッと、しかも依存の無い、クロスビルドと比べたら相当面倒。
しかもcopreemptiveじゃん。
色々な意味でGoの相手ではない。

32(1): デフォルトの名無しさん [sage] 2022/02/28(月) 20:02:32.92 ID:pJo2hpV4(1) AAS
>>31
どちらもメリット・デメリットあるからそれは言いすぎでしょ
しかも肝心な速度でGoが負けているのだから用途ごとに使い分ければよい話

33(1): デフォルトの名無しさん [sage] 2022/02/28(月) 20:20:38.66 ID:qPXeLVFX(4/5) AAS
>>32
その通り、メリデメある、使い分ければ良い→その時点で「相手ではない」と言ってる。
ずっと言ってるけど、1番2番論争は無意味なんよ。
速度ばかりが大切な訳でも無いんだし。

34: デフォルトの名無しさん [sage] 2022/02/28(月) 21:17:53.06 ID:qPXeLVFX(5/5) AAS
これ貼っとくわ。
https://thenewstack.io/enough-with-the-zero-sum-game-of-rust-vs-go/

35(1): デフォルトの名無しさん [sage] 2022/02/28(月) 21:21:31.32 ID:BEDnUIJv(2/3) AAS
>>23
いや、元記事もそこはちょっと間違ってる。
とはいえ本質は「RSSで全部計上されてるか？」なので大筋は問題ないが。

RSSは「ユーザープロセス空間で、メモリ上に配置されてる物」なので、元記事の通り、スワップされてれば計上されないが、
そもそもこの計測方法では普通はスワップされない。
ただ、考慮してるのは"Thread bookkeeping"であって、
kernel(OS)がこれに使うメモリがRSSに計上されてないから問題だ、というのはあってる。
だから俺はそれを足してる。

Goでは、実はこの部分も売りにしてて、以下は8の2つ目だが
> https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast
> The switch between goroutines only happens at well defined points, when an explicit call is made to the Go runtime scheduler.
> The compiler knows the registers which are in use and saves them automatically.
むやみにプリエンプトせず、スイッチングポイントを考えて、必要ないレジスタは待避してない。
考えられるのは
・そもそもセグメントレジスタなんて普通は使わないから待避する必要がない。（レガシー）
・関数の途中でプリエンプトせず、関数呼び出し単位でスイッチなら、
呼び出し規約上の破壊レジスタ(a,b,c,d)は待避する必要がない。
・そのgoroutineの処理にSSE命令が存在しなければ、SSE系レジスタを待避する必要がない。FPU(x87)も同様。
とかになる。
(なおこれを突き詰めたらRustの「コルーチンのyieldでスイッチすれば、スタックも要らん」になる)
そして現実的に多くの場合SSE系命令は不要で、必要待避領域は多分半分以下にはなるので、（面倒だから数えてないが）
Goは半分以下にする努力してるのにRSSだと計上され、OS任せだと丸々必要なのにRSSには計上されないので、
当然の如く突っ込まれる事になる。
（その他細かいフラグ類は沢山あるだろうけど、多くはbit単位であり容量としてはゴミなので無視)

だから最小フットプリントなら1/3程度で、
あまり余計なことしなければスイッチングコストも1/3程度としていいのではないかと。
逆に言えば、threadよりも3倍程度のgoroutineで済むのなら、速くてコードも綺麗だが、
それ以上なら遅くなるという事。

36: デフォルトの名無しさん [sage] 2022/02/28(月) 21:59:11.85 ID:BEDnUIJv(3/3) AAS
>>27,28
どこから突っ込めば状態なので、最初の部分だけ。

> nodeでasync/awaitが通るのは、シングルスレッドですべてのメモリーが一緒のためで、
これは多分プロセスとスレッドの区別が出来てない。
プロセスは別空間だがスレッドは同一空間で、逆に言えばその程度の違いしかないが。
> e.g. Linux doesn’t distinguish between threads and processes and both are called tasks.
> https://codeburst.io/why-goroutines-are-not-lightweight-threads-7c460c1f155f#396b

> Goのようにgoroutineで実際に割り当てられているCPUやスレッドが分からないようにあえてしている言語で
一般的に非同期の場合はどのCPUにどの順番で処理されても動くように組む必要があり、
実際にC#でもそう。
JSもそう。(ただしJSのプログラミングモデルからは見えない)
この発言は上記の勘違い、（とは言っても普通の勘違いとは逆で）
Goはgoroutineがそれぞれ「別空間」で動いていると勘違いしてるからだと思うのだが、それはない。
重ならないようにコンパイラが割り当ててくれてるだけで、同一空間だ。

37(1): デフォルトの名無しさん [sage] 2022/02/28(月) 22:40:05.81 ID:EeqSDih1(3/3) AAS
>>35
元記事はGoのバージョンが確認できず、goroutine当たりのスタックサイズは不明なため、断定してないだけで、時期を考えると2KBだから恐らくRSSだろうとは思っている(明確に言えるのは自分で計測した方だけ)。
カーネルで管理されているメモリは4KB/2KBとかじゃないと思うし、数字としてはどこにも表れないので、それは差があるとだけしておけばいい。
元記事の筆者が加算しているのはgoroutineスタック分以外は全てRSSに入る前提の元、未計測の仮想メモリには最大40MB入ることがあるはずという計算。

> Goでは、実はこの部分も売りにしてて、以下は8の2つ目だが...コルーチンのyieldでスイッチ...
Goの「スイッチングポイント」は現状誰も明示しておらず、保存しているものも、どこなのかも、推測の範疇を出ておらず、議論は無意味。

38(2): デフォルトの名無しさん [sage] 2022/02/28(月) 23:44:04.73 ID:7SSxP2tw(2/2) AAS
>>33
Rustはどう見てもGoの相手でしょう
2019年に非同期本対応のRustが誕生するまでは明らかにGoの独壇場だった
今はRustがGoと同様にN:M非同期タスクを実現してGoのようにチャネルを使って全く同じ動作が可能となった上でasync/awaitも対応
そしてRustのほうが速いのだから比較対象として話が出るのは仕方ない

39(2): デフォルトの名無しさん [sage] 2022/03/01(火) 00:33:28.48 ID:OK3fXqHC(1/3) AAS
>>37
> goroutineスタック分以外は全てRSSに入る前提の元
いやgoroutineスタック分はユーザー空間だからスワップアウトされてない限りRSSには計上される。
そしてスワップアウトは「必要ない限りやらない」のが基本だから普通にベンチマークしてれば問題ない。
(同時にメモリイーターなプロセスを走らせておかないと速攻スワップアウトなんてされない）

> カーネルで管理されているメモリは4KB/2KBとかじゃないと思うし
『プロセス』を管理するために必要なカーネル側のメモリは4kBとかではない。
PTE(PageTableEntry=MMUの中身データ）だけでもメモリ128MBなら4k/pageだと128kB(=32kentry*4Bytes)必要になる。
（ただしラージページ《2M/page》なら256Bytesで済むが)
だから『プロセス』は軽くない。

一方、『スレッド』についてはこの部分は必要なく、追加のスレッドによって増えるカーネル側メモリは、
スレッド管理分のフラグ類の数Bytesと、待避領域の1kBだけで済むはず。
4k/threadの見積もりは多すぎ。(多分)

> Goの「スイッチングポイント」は現状誰も明示しておらず、保存しているものも、どこなのかも、推測の範疇を出ておらず、議論は無意味。
それはそうだが、多分合ってると思うよ。ただ、
> どこなのかも、
これについては間違いなくユーザー空間のはずだよ。カーネル側に保存する意味がないし、余計に遅くなる。
誤解無いようにくどいが言っておくと、
OSの管轄でマシンスレッドからプリエンプトする場合、各マシンスレッドの状態待避はカーネルがカーネル空間側に行う。
Goランタイムの管轄でgoroutineを切り替える場合、各goroutineの状態待避はGoランタイムがユーザー空間側に行う。
(まさかGoランタイムってカーネルモードで動いてたりする？それなら話は違ってくるが)

40(1): デフォルトの名無しさん [sage] 2022/03/01(火) 00:41:23.65 ID:LFBfp70W(1/3) AAS
>>38
明らかにユースケースが違うし、コンビニに行くのにF1乗るみたいな話だぞそれ。
スクーター以上のそれなりに早い二輪車が欲しいんだよ。

41(1): デフォルトの名無しさん [sage] 2022/03/01(火) 00:47:33.18 ID:LFBfp70W(2/3) AAS
>>39
違うのでは？
ユーザスレッドでもカーネルスレッドでも動いてる。
普段はgoroutineはユーザ空間で動いてるが、その上でカーネルスレッド毎に偏りがあったらスティールするでしょ。

42(1): デフォルトの名無しさん [sage] 2022/03/01(火) 00:59:49.19 ID:OK3fXqHC(2/3) AAS
>>41
君は27？

> 普段はgoroutineはユーザ空間で動いてるが、その上でカーネルスレッド毎に偏りがあったらスティールするでしょ。
これは明らかに分かってない奴の言い分だが。

43(1): デフォルトの名無しさん [sage] 2022/03/01(火) 01:09:17.06 ID:MT73K7Vw(1/3) AAS
>>39
> > goroutineスタック分以外は全てRSSに入る前提の元
> いやgoroutineスタック分はユーザー空間だからスワップアウトされてない限りRSSには計上される。
だから元記事の筆者がそう考えているという話で、これは俺の環境とは違うからRSSなのか仮想メモリなのか断定できないと言ってるだけ。
よく読んで欲しい。

> > どこなのかも、
> これについては間違いなくユーザー空間のはずだよ。カーネル側に保存する意味がないし、余計に遅くなる。
アドレス空間の話ではなく、スイッチングポイントは典型的にはyield直前とかのはずなんだけど、そこ実際にどこだか誰も調べてないよね？と言ってる。
多分とか入るのに他所様のお庭と比較するのはおこがましい。

44(1): デフォルトの名無しさん [sage] 2022/03/01(火) 01:58:03.77 ID:OK3fXqHC(3/3) AAS
>>43
> だから元記事の筆者がそう考えているという話で
それはそうだが、俺らはそのデータを見てる立場なので、それが正しいかをチェックする事になるだろ。
これも誤解無いように言っておくと、
元記事の作者は、(彼的には)正しいと思ってるからそう書いている。俺から見てもRSSで問題なく、正しくデータは取れてると思う。
(ただし考察の一部に微妙に間違いが含まれているので、その部分を指摘してるが、大局に影響はない)
ちなみに君のデータも、正しく取れてて、問題ないように見える。
RSSでいいのか心配のようなので、こちらからも「RSSで問題ない」との意見を付けた。

> アドレス空間の話ではなく
上記RSSの話に引っ張られてしまって勘違いした。すまん。

これ以上進めるには精度が足りないというのは了解した。
俺的にはこの程度の精度でも前進して構わないというノリなのだが、
もっと厳密に正確に確認していきたい人だとストレスが溜まるとは思う。
掘り下げたい人がいれば、12みたいにソースの該当箇所を提示してくれれば、確認の手伝いくらいはする。

45: デフォルトの名無しさん [sage] 2022/03/01(火) 02:03:09.66 ID:LFBfp70W(3/3) AAS
>>42
24とか。
どう違うん？

46(2): デフォルトの名無しさん [sage] 2022/03/01(火) 06:28:53.29 ID:MT73K7Vw(2/3) AAS
>>44
了解。すまんがこれ以上は俺はやらない。main.goのスレッド数に対するRSSのグラフ(svg)だけ貼っとく。
https://jsfiddle.net/9b0kujsL/
そのうち消えると思うけど、ここには貼れないサイズだったので仕方ない。

47: デフォルトの名無しさん [sage] 2022/03/01(火) 08:12:28.20 ID:aFcqKDVR(1) AAS
>>38
Rustのビルド速度は凄まじく遅いだろ。競合にならん。

Rust信者はgoスレに書き込む前に"Build fast, reliable, and efficient software at scale"を100万回唱えろ。

48: デフォルトの名無しさん [sage] 2022/03/01(火) 09:03:50.60 ID:cUOzOJ3p(1) AAS
昔は遅かった
今は特に問題ない

49: デフォルトの名無しさん [sage] 2022/03/01(火) 10:19:27.41 ID:NXJnvaYt(1) AAS
今も結構遅いけどな…ま、気にする必要はないが

50: デフォルトの名無しさん [sage] 2022/03/01(火) 11:47:54.41 ID:IZ7MnaYC(1) AAS
気になるだろ…

51: デフォルトの名無しさん [sage] 2022/03/01(火) 11:58:08.47 ID:MT73K7Vw(3/3) AAS
>>46
うっかりスレッドって書いちゃったけどgoroutineの間違いです(グラフも)

52: デフォルトの名無しさん [sage] 2022/03/02(水) 00:08:09.90 ID:A3d3IcmJ(1/3) AAS
>>46
了解。では感想だけ。
今時はグラフはsvgで作るのかーとちょっと驚いた。ググったら結構あるみたいだけどさ。まあそれはさておき、

> f(x) = 2.6396 x + 1186.8
完全にリニアで、2kBはスタックとして、残り0.6はちと多い。G構造体は以下(前スレ805内のリンク内)
https://github.com/golang/go/blob/master/src/runtime/runtime2.go#L403-L498
にあるが、51個もメンバがある巨大構造体で、こんなに必要なのか？とは思う。
まあ「税金」として0.6kBかかるのなら、無理にスタックを1kBにケチる意味はないから、デフォ2kBは妥当な判断に見える。
これについてはlinuxと比較しないと妥当性は検討出来ないが、

妥当性を検討するためにはLinuxを見る必要がある。これは同様に(前スレ805内の記事11章)以下にある。
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/sched.h#n657
見た目goよりでかいし、ifdefが多すぎて数える気にすらならない。

とはいえlinuxのはプロセスと共用だし、そもそも大量に起動する用途向けではないので多少大きくても問題ない。
おそらくあれこれ機能を足していくうちに肥大化したのだろうとは思う。
ただこれに対抗するならgoのはでかすぎ。
10倍起動するつもりなら、サイズは1/10に抑えないと並べない。(今は多分数分の一程度)
JSはここら辺はただのFIFOで、1ジョブ当たりポインタ数個分で実装出来る程度の機能しかない。だから速い。
Goのも既に肥大化しすぎてる。
ちょっと考えてみ？600Bytes=ポインタ*75個分で、一体何の制御をしたらそんなに必要なのかと。
51個のメンバがある＝起動/停止時にその51個のメンバをチェック/更新するコードを通す事になる
＝起動/停止時に「税金」的に数百サイクルは必要、となる。

53: デフォルトの名無しさん [sage] 2022/03/02(水) 00:08:36.44 ID:A3d3IcmJ(2/3) AAS
ここら辺はやっぱりチューニングが狂ってる。
『軽量』OSじゃないといけないんだけど、
オレオレOS作りたい奴がランタイム作ってて機能が肥大化してるのではないかと。
スケジューラが売りのようだが、ベアメタルではなくOS上で動かすのだから、無くてもOS側がそれなりにはやってくれる。
それをスケジューラ作りたいだけの奴が作っただけのように見える。
アプリを速くしたいのではなく、スケジューラを作り込みたいだけだから、チューニングが狂う。
この辺、JSはエンジン内の仕組みなんて誰も評価しないでしょ。
速いか遅いかだけ。だからチューニングが狂わない。

54(1): デフォルトの名無しさん [sage] 2022/03/02(水) 01:42:28.65 ID:WG8WfuCM(1/2) AAS
OSがそれなりにさばかないよ。グリーンスレッドの価値を全否定だな。

JSのエンジン、定期的に話題になるだろ。
V8もTurbofan+Ignitionに変わってすぐはソース読んでたぞ。

55(1): デフォルトの名無しさん [sage] 2022/03/02(水) 03:09:53.11 ID:re9dUtRi(1/9) AAS
https://jsfiddle.net/z1bvwt3L/1/
1:1スレッドでのC++/Rustの結果も併記した(Rustのバージョンは1.58.1)
標準機能で記述する縛りでロジックだけ同じにすると現状ではこうだということ
M:NをC++/Rustで自前準備すれば別の比較ができるかもね

56: デフォルトの名無しさん [sage] 2022/03/02(水) 03:13:52.18 ID:re9dUtRi(2/9) AAS
あ、C++はgcc9.3、C++14で記述。

57(1): デフォルトの名無しさん [sage] 2022/03/02(水) 03:34:51.80 ID:S8+3WyDZ(1/4) AAS
>>55
全く意味のない比較になっている
Goではm:nグリーンスレッド利用
C++とRusyでは1:1つまりOSスレッド利用
ちゃんと3者ともにm:nグリーンスレッド利用で比較しなさい

58(2): デフォルトの名無しさん [sage] 2022/03/02(水) 04:07:09.47 ID:re9dUtRi(3/9) AAS
>>57
「標準機能で記述する縛りでロジックだけ同じ」という条件だとそれは無理な相談
むしろm:nでないとならない条件では成立しない

> ちゃんと3者ともにm:nグリーンスレッド利用で比較しなさい
上記条件にはならないが、どうしてもやりたければお前がやれ
C++は20を使えば標準機能だけで実装できるはず
Rustが標準機能だけで実装可能かは知らない

59: デフォルトの名無しさん [sage] 2022/03/02(水) 06:39:48.32 ID:re9dUtRi(4/9) AAS
Rustの標準ライブラリはunsafeのオンパレードだなｗ

60: デフォルトの名無しさん [sage] 2022/03/02(水) 06:40:13.75 ID:re9dUtRi(5/9) AAS
誤爆

61: デフォルトの名無しさん [sage] 2022/03/02(水) 07:09:40.23 ID:fOFAuz8H(1) AAS
ライブラリもOS機能を使うならunsafeも致し方ないのではないだろうか、と誤爆にレス

62: デフォルトの名無しさん [sage] 2022/03/02(水) 08:03:15.38 ID:re9dUtRi(6/9) AAS
興味があるならどこの誤爆かだけ書いておく
2chｽﾚ:tech

63(1): デフォルトの名無しさん [sage] 2022/03/02(水) 09:14:57.44 ID:WG8WfuCM(2/2) AAS
>>58
わざわざGoスレでくだ巻いてる方がやれよ。
できなけりゃGoを使うよ。

64(4): デフォルトの名無しさん [sage] 2022/03/02(水) 12:54:03.99 ID:re9dUtRi(7/9) AAS
>>63
俺はGoのパフォーマンス測定をGoスレで尋ねてその後も調査してるだけだけ(すでに終了は宣言した)
ただまだ妥当性がどうのと言ってる人がいるから、とりあえず恐らく同じくデフォルトが通常2KなOSスレッドスタックを使ったRustとC++の結果を貼っただけ
結果は1:1でthreadが動いてるRust/C++の完敗だが、ロジック同程度で標準機能だけという条件なら仕方ないねって話をしただけだぞ
まだ文句があるなら自分でやれと言って何が悪い
お前がGoを使おうと何を使おうと俺はどうでもいい

65(1): デフォルトの名無しさん [sage] 2022/03/02(水) 14:10:00.74 ID:S8+3WyDZ(2/4) AAS
>>64
m:nとなるgoroutineを用いたGoと
1:1となるOSスレッドだけを用いたC++&Rustを比較することは無意味
比較したいならばC++&Rust側でもm:nでやりなさい

66(1): デフォルトの名無しさん [sage] 2022/03/02(水) 15:24:10.33 ID:mFEJLP5N(1) AAS
>>64
勝ち負けを認めさせたいから言ったのでは無く、それ以上はRustスレでやれと言ってる。

67: デフォルトの名無しさん [sage] 2022/03/02(水) 16:34:57.55 ID:re9dUtRi(8/9) AAS
>>66
俺に言うなよ
>>65に言え

68: デフォルトの名無しさん [sage] 2022/03/02(水) 16:54:30.69 ID:S8+3WyDZ(3/4) AAS
C++スレでもRustスレでもここでも同じで無意味
m:nとなるgoroutineを用いたGoと
1:1となるOSスレッドだけを用いたC++&Rustを比較することはナンセンス

69: デフォルトの名無しさん [sage] 2022/03/02(水) 17:04:08.05 ID:re9dUtRi(9/9) AAS
thread単品で制御できないgoじゃこういう計測ができないのも理解できないとは・・・
何しにgoスレに来てるのやら

70: デフォルトの名無しさん [sage] 2022/03/02(水) 17:33:02.75 ID:S8+3WyDZ(4/4) AAS
C++とRustでもOSスレッドではなくm:nグリーンスレッドを使えばよいだけだろ

71(1): デフォルトの名無しさん [sage] 2022/03/02(水) 23:43:26.42 ID:A3d3IcmJ(3/3) AAS
>>64
妥当性がどうのこうのは「GoランタイムのG実装」であって、君のデータについてではない。
君のデータは妥当だし正確だと思うよ。

>>54
> OSがそれなりにさばかないよ。
GOMAXPROCSがCore数と同じ事に拘ってるからだよ。だから完全な（＝高価な）スケジューリングが必要になる。
Core数よりも多いMにして、優先順位を低く設定しておけば、CPUが空いてればそのMで実行される。（これはOSがやってくれる）
これなら今のランタイムがやってるようなスケジューリング管理なんて丸々必要なくなる。
C#がこれで、空きCPUがあれば新規スレッドをプールに追加して、実行させるだけでしょ。
(ただしGoの場合は同期チャネルなので一々止まりまくり、この場合は確かにそのままOSに任せても駄目で、
Rustみたいに同期受信待ちをコルーチン化して送信時に受信側goroutineのコードを直接実行する実装の方が向いてるが、
《だからthreadなのにコルーチンと名付けたのか？》
ここら辺はジョブの重さと同期チャネル量の兼ね合いで、第一選択肢として力業（スケジューラ）で解決、という判断は妥当ではあるが)

> グリーンスレッドの価値を全否定だな。
「コンテキストスイッチのオーバーヘッドを減らす」Goより、
「コンテキストスイッチ自体を無くす」非同期の方が原理的に速い。
ただし非同期はソースがうざかったが、async文法でまあ何とかなった。
よって肯定する部分がない。当然他言語も全く追従しない。（今後出てくるかもだが）
逆に非同期はJS/C#/Rustと来てるだろ。良いと見られている証拠。

> V8もTurbofan+Ignitionに変わってすぐはソース読んでたぞ。
それは君が興味があるからだろ。
大半のJSerはC++は読めないし、読む気もない。ブラウザが速ければそれで良しだよ。

わざわざ自前でスレッド管理するのなら、OSと被ってないところをやらないと。
スケジューリングはOSがやってくれるのだから任せておけばいいし、自前でやっても余計に遅くなるだけ。
残ってるとすればスレッド間通信で、これは確かにOSのは遅い、というより動くようにしか出来てない。（そして非同期）
だからそこそこ速い同期チャネルが絶対不可欠なアプリがあれば、と思って考えてみたが、やっぱり俺は思いつかないね。

72: デフォルトの名無しさん [sage] 2022/03/03(木) 00:21:30.68 ID:r4JzAqw4(1/2) AAS
やり方がわからんのだろ。

73(1): デフォルトの名無しさん [sage] 2022/03/03(木) 00:23:05.45 ID:r4JzAqw4(2/2) AAS
チャンネルが同期なのはバッファが無いとき
お前は本当に人な話を聞かないし何も読まないな。

74(2): デフォルトの名無しさん [sage] 2022/03/03(木) 00:56:08.72 ID:hTxF5AaQ(1/2) AAS
>>71
> 妥当性がどうのこうのは「GoランタイムのG実装」であって、君のデータについてではない。
うん、それは分かってたんだけど、定量的なデータがないとその妥当性分からんでしょ
M:Nのgoroutineだからと言って調子に乗って1:1の10倍積むと、俺の環境だとrssは超えてしまうってことがデータから分かる
データは簡単に取れる状況だったから、取っただけ

75: デフォルトの名無しさん [sage] 2022/03/03(木) 11:28:44.36 ID:6vq1sG3T(1/5) AAS
Windowsでアップデート後にVScodeでテストを走らせると1.14.13でコンパイルされてるためツールバージョン1.17.7とマッチしませんと言われる
setting.jsonでgo.gopathを環境変数のGOPATHに合わせてビルドしてもダメ
かといってアップデートされたディレクトリを指定してもダメ

環境変数のGOPATHのgo.exeがアップデートでは更新されていないためなのか
でもツール類はアップデートされてたりしてもう訳がわからない
どう処置したらいいの？

ちなみに、システム環境変数のPathには$GOPATH\binのパスが入れてある

76: デフォルトの名無しさん [sage] 2022/03/03(木) 11:44:33.79 ID:6vq1sG3T(2/5) AAS
いや…落ち着いてエラーログを見たら、例えばruntime/internal/sysが、とか言ってる
参照モジュール？

で、go.sum を消して再ビルドしたけど同じ結果

77: デフォルトの名無しさん [sage] 2022/03/03(木) 13:27:09.03 ID:6vq1sG3T(3/5) AAS
とりあえず全部をアップデート先に統合する方向で納めた
バージョン混在状態だとどうしたらベストなのだろう？
環境的には最新に統合してgo.modでのバージョン記述に頼ればいい？

78: デフォルトの名無しさん [sage] 2022/03/03(木) 18:20:17.50 ID:qZcuxxc0(1) AAS
>>74
つまりリソース的にGoroutineはOSのスレッドの数倍しか立ち上げられないということ？

79: デフォルトの名無しさん [sage] 2022/03/03(木) 18:47:19.32 ID:3iRkjbfP(1) AAS
https://zenn.dev/mattn/articles/c453f42393778a
numpy より速い？Go の行列演算ライブラリ nune

やっぱＧＯは速いね

80(1): デフォルトの名無しさん [sage] 2022/03/03(木) 20:31:53.54 ID:DvSNmo59(1/2) AAS
>>74
それはご丁寧にどうも。ついでなら、
> C++は20を使えば標準機能だけで実装できるはず (>>58)
これについてもキーワードかURLだけでも教えてくれれば助かる。見に行く。
greenthreadが採用されたって事か？
(C++の場合は『全部入り』を目指してるからいつかは入るとは思うが）

>>73
あの文法は同期が主目的で非同期も問題なく書けるだけ。

OSのスレッド間通信は非同期しかなく、
同期したければ自前でループかサスペンド/ウェイクアップするしかない。
だからそんなに同期を取る事はなく、仕方なくやる程度。
そしてそれで何とかなってる＝従来分野は非同期で問題なく書けてる。

同期の場合、シェークハンド等の単純な方法なら同期プリミティブ無しで書ける。
多分もっと複雑な事も出来るのだろう。だけど俺にはそれに適した分野が分からない。
(従来分野は問題ないので、従来既に困ってたか新分野かだが、思いつかない)

ランタイムの仕様が無駄に大きいと、実行速度がそのまま低下する。
JSが無駄に速いのは、仕様が小さい(最小限に絞ってる)のもある。
チャネルの実装は以下(前スレ805内リンク8章)にあるが、
https://zenn.dev/hsaki/books/golang-concurrency/viewer/chaninternal
こんなまどろっこしい実装になってる理由は、同期（も出来る構造）だからだ。
非同期専用ならもっと単純な実装で済むし、速い。

だから優位性を発揮するためには、「同期チャネル」がないと辛いアプリがあれば分かりやすいが、
俺には今のところ思いつかないって話。
（非同期チャネルだと「空になったら止まる」という間抜けな同期しか出来ないが、実際それで十分という話）

81(1): デフォルトの名無しさん [sage] 2022/03/03(木) 20:56:08.85 ID:hTxF5AaQ(2/2) AAS
>>80
coroutine

82: デフォルトの名無しさん [sage] 2022/03/03(木) 21:23:47.28 ID:DvSNmo59(2/2) AAS
>>81
あ、そういう事ですか、なるほど。

まあ見てみましたが、相変わらずというか、何というか。
https://cpprefjp.github.io/lang/cpp20/coroutines.html

83: デフォルトの名無しさん [sage] 2022/03/03(木) 21:54:21.27 ID:oaR2p1R0(1) AAS
Docker CLIのダウンロードみたいな
複数のプログレスバーを出せるライブラリほしい
何がおすすめ？

84: デフォルトの名無しさん [sage] 2022/03/03(木) 22:06:45.01 ID:6vq1sG3T(4/5) AAS
GUIなぞ基本的には管轄外です
お引き取りを

85: デフォルトの名無しさん [sage] 2022/03/03(木) 22:22:12.59 ID:y+UC/h2K(1) AAS
CLIでのプログレスバーの話だろ？

86: デフォルトの名無しさん [sage] 2022/03/03(木) 22:27:14.50 ID:6vq1sG3T(5/5) AAS
あーすまん

87: デフォルトの名無しさん [sage] 2022/03/03(木) 23:09:26.23 ID:1IkAc1iQ(1) AAS
いいってことよ

88(1): デフォルトの名無しさん [sage] 2022/03/03(木) 23:29:47.34 ID:Rf6M0oqn(1) AAS
>>64
そこは標準機能だけ対象といってもその定義が難しい
そのRustは標準(std)ライブラリーは最小限のものしかなくて
例えば乱数も暗号関係(TLS含む)も正規表現もJSONもHTTPも非同期ランタイムも何もかもstdに含まれていない
全てデファクトスタンダードで賄う方針だからそれらを標準機能として採用して比較してよい？

89: デフォルトの名無しさん [] 2022/03/03(木) 23:35:59.34 ID:vRr517/c(1) AAS
rustはもう少し標準ライブラリにも機能増やして欲しい。

90: デフォルトの名無しさん [sage] 2022/03/04(金) 00:05:33.31 ID:4zB49VIz(1/4) AAS
>>88
俺が依頼してる話でもないから俺に聞かれても・・・ではある。そもそもここgoスレだし何のためにそれをしたいのかすら分からない。

単純に話を聞く限り
・goは言語機能で賄っているのに標準ライブラリ以外を使うとか流石に比較にならないと思う
・C++の標準ライブラリにもjsonやhttpや暗号はない
・同じロジックにこだわらず、追加のロジックで不足機能を補うなら、可搬性(プラットフォームごとに実行コードが変わらない)が必要
のではないかと思う

91(2): デフォルトの名無しさん [sage] 2022/03/04(金) 07:00:31.23 ID:Ah997PWW(1) AAS
非同期処理ですら紛糾して仕上がったのが2019/11な赤ん坊に無茶言うなって
Rustのコンセプトは分かるけど、学習難易度とライブラリの貧困さを何とかしないと浮かばれずにいつの間にか沈むぞ

92(1): デフォルトの名無しさん [sage] 2022/03/04(金) 11:17:26.10 ID:2Vo/u60a(1) AAS
そんなにライブラリ貧困なの？
おれもまだ勉強中なんだけど何のライブラリで困るのか具体的に教えてくれ
勉強がてら試しに作ってみるかも

93: デフォルトの名無しさん [sage] 2022/03/04(金) 13:21:46.53 ID:JMvj/uct(1/4) AAS
>>91
学習難易度はキノコードが動画作れば解決w

94: デフォルトの名無しさん [sage] 2022/03/04(金) 15:27:21.82 ID:e8gLPWot(1/4) AAS
>>91
Rustも難易度は高くなくて広く色んなプログラミング言語をやってきた者には容易
例えばC言語などのenumを関数型言語の代数的データ型で拡張したのがRustのenum
そういうのを理解しているとメソッドによる代数的演算やパターンマッチングなどRustの基本機能も習得がすぐ
あるいは例えばGoでも構造体ベースのイテレータパターンを書いたことあればRustのイテレータも楽勝といった具合
GoやCのfor ; ; 文はRustには存在せずイテレータに集約されており更にメソッド連鎖させて操作の分離と抽象化でわかりやすく書くことが多い

95(1): デフォルトの名無しさん [sage] 2022/03/04(金) 15:37:03.27 ID:e8gLPWot(2/4) AAS
>>92
むしろRustは民主主義方式なのでライブラリは多種多様に豊富
異なる考え方で作られたものが両立している分野もあるし後から優れたものが出てきてシェア拡大も起きたりしている
代わりに標準ライブラリ(std)は必要最小限のものしかなく
その一部であるコア標準ライブラリ(core)はヒープがなくても動作する更なる最小セットを提供

96(10): デフォルトの名無しさん [sage] 2022/03/04(金) 15:39:19.04 ID:4zB49VIz(2/4) AAS
間違ってる上にスレ違いすぎるな

言語比較がしたいなら↓へ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
2chｽﾚ:tech

97(1): デフォルトの名無しさん [sage] 2022/03/04(金) 15:48:00.84 ID:e8gLPWot(3/4) AAS
>>96
間違ったことは書いていない
質問や話題があったからそれに対して答えたまで

98: デフォルトの名無しさん [sage] 2022/03/04(金) 15:52:46.98 ID:4zB49VIz(3/4) AAS
>>97
>>96

99(1): デフォルトの名無しさん [] 2022/03/04(金) 16:07:29.53 ID:wUg1CCTJ(1/2) AAS
>>95
民主主義方式はc++みたいに標準委員会方式の場合だろ。
実装複数でデファクトスタンダードを競わせるってのは戦国時代方式だよ。

100(1): デフォルトの名無しさん [sage] 2022/03/04(金) 16:41:14.71 ID:2tyOtSaX(1/2) AAS
>>99
あの標準委員会方式は強いて言えば一党独裁制だが紛糾ちぐはぐに近い
そしてC++の標準拡張が失敗してきた歴史を見ても反面教師としたのは理解できる

上下前次 1-新書関写板覧索設栞歴

あと 902 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.030s