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/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に変更は出来るか確認出来ると思うけど、面倒なのでそこまではしない。

**デフォルトの名無しさん** · 2022/02/28(月) 01:17:28.02

反論はそこだけ？

**デフォルトの名無しさん** · 2022/02/28(月) 01:18:12.57

>>21
これだけ指摘されて、まだスレッドだと思ってるのは少ないのでは？

**デフォルトの名無しさん** · 2022/02/28(月) 01:33:25.66

一般には
coroutine + thread -> goroutine, async/await
という認識の人が多数だと思う

**デフォルトの名無しさん** · 2022/02/28(月) 14:52:59.85

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

**デフォルトの名無しさん** · 2022/02/28(月) 15:07:48.45

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でも投下してこい。それすら出来ないなら
お前は不当に他言語を卑下してる卑怯者だぜ。どうせボコボコにされる

**デフォルトの名無しさん** · 2022/02/28(月) 15:52:51.20

>>27
流石にその理解はヤバいぞ
asyncおじさんをバカにしてる場合じゃない

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

>>27
その主張は間違い
例えば現実にある反例として
RustでもGoと同じくワークスティーリングをするM:Nモデルで非同期タスクが動きasync/awaitが導入されている

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

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

Rustでもできる、は聞き飽きたんだが、Rust話がしたいのか？
Rustの話はRustスレで聞きたいんだが、とうしてRustスレではN:Mグリーンスレッドの優位性の話してないの？

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

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

>>31
どちらもメリット・デメリットあるからそれは言いすぎでしょ
しかも肝心な速度でGoが負けているのだから用途ごとに使い分ければよい話

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

>>32
その通り、メリデメある、使い分ければ良い→その時点で「相手ではない」と言ってる。
ずっと言ってるけど、1番2番論争は無意味なんよ。
速度ばかりが大切な訳でも無いんだし。

**デフォルトの名無しさん** · 2022/02/28(月) 21:17:53.06

これ貼っとくわ。
https://thenewstack.io/enough-with-the-zero-sum-game-of-rust-vs-go/

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

>>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で済むのなら、速くてコードも綺麗だが、
それ以上なら遅くなるという事。

**デフォルトの名無しさん** · 2022/02/28(月) 21:59:11.85

>>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がそれぞれ「別空間」で動いていると勘違いしてるからだと思うのだが、それはない。
重ならないようにコンパイラが割り当ててくれてるだけで、同一空間だ。

**デフォルトの名無しさん** · 2022/02/28(月) 22:40:05.81

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

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

**デフォルトの名無しさん** · 2022/02/28(月) 23:44:04.73

>>33
Rustはどう見てもGoの相手でしょう
2019年に非同期本対応のRustが誕生するまでは明らかにGoの独壇場だった
今はRustがGoと同様にN:M非同期タスクを実現してGoのようにチャネルを使って全く同じ動作が可能となった上でasync/awaitも対応
そしてRustのほうが速いのだから比較対象として話が出るのは仕方ない

**デフォルトの名無しさん** · 2022/03/01(火) 00:33:28.48

>>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ランタイムってカーネルモードで動いてたりする？それなら話は違ってくるが)

**デフォルトの名無しさん** · 2022/03/01(火) 00:41:23.65

>>38
明らかにユースケースが違うし、コンビニに行くのにF1乗るみたいな話だぞそれ。
スクーター以上のそれなりに早い二輪車が欲しいんだよ。

**デフォルトの名無しさん** · 2022/03/01(火) 00:47:33.18

>>39
違うのでは？
ユーザスレッドでもカーネルスレッドでも動いてる。
普段はgoroutineはユーザ空間で動いてるが、その上でカーネルスレッド毎に偏りがあったらスティールするでしょ。

**デフォルトの名無しさん** · 2022/03/01(火) 00:59:49.19

>>41
君は27？

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

**デフォルトの名無しさん** · 2022/03/01(火) 01:09:17.06

>>39
> > goroutineスタック分以外は全てRSSに入る前提の元
> いやgoroutineスタック分はユーザー空間だからスワップアウトされてない限りRSSには計上される。
だから元記事の筆者がそう考えているという話で、これは俺の環境とは違うからRSSなのか仮想メモリなのか断定できないと言ってるだけ。
よく読んで欲しい。

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

**デフォルトの名無しさん** · 2022/03/01(火) 01:58:03.77

>>43
> だから元記事の筆者がそう考えているという話で
それはそうだが、俺らはそのデータを見てる立場なので、それが正しいかをチェックする事になるだろ。
これも誤解無いように言っておくと、
元記事の作者は、(彼的には)正しいと思ってるからそう書いている。俺から見てもRSSで問題なく、正しくデータは取れてると思う。
(ただし考察の一部に微妙に間違いが含まれているので、その部分を指摘してるが、大局に影響はない)
ちなみに君のデータも、正しく取れてて、問題ないように見える。
RSSでいいのか心配のようなので、こちらからも「RSSで問題ない」との意見を付けた。

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

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

**デフォルトの名無しさん** · 2022/03/01(火) 02:03:09.66

>>42
24とか。
どう違うん？

**デフォルトの名無しさん** · 2022/03/01(火) 06:28:53.29

>>44
了解。すまんがこれ以上は俺はやらない。main.goのスレッド数に対するRSSのグラフ(svg)だけ貼っとく。
https://jsfiddle.net/9b0kujsL/
そのうち消えると思うけど、ここには貼れないサイズだったので仕方ない。

**デフォルトの名無しさん** · 2022/03/01(火) 08:12:28.20

>>38
Rustのビルド速度は凄まじく遅いだろ。競合にならん。

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

**デフォルトの名無しさん** · 2022/03/01(火) 09:03:50.60

昔は遅かった
今は特に問題ない

**デフォルトの名無しさん** · 2022/03/01(火) 10:19:27.41

今も結構遅いけどな…ま、気にする必要はないが

**デフォルトの名無しさん** · 2022/03/01(火) 11:47:54.41

気になるだろ…

**デフォルトの名無しさん** · 2022/03/01(火) 11:58:08.47

>>46
うっかりスレッドって書いちゃったけどgoroutineの間違いです(グラフも)

**デフォルトの名無しさん** · 2022/03/02(水) 00:08:09.90

>>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個のメンバをチェック/更新するコードを通す事になる
＝起動/停止時に「税金」的に数百サイクルは必要、となる。

**デフォルトの名無しさん** · 2022/03/02(水) 00:08:36.44

ここら辺はやっぱりチューニングが狂ってる。
『軽量』OSじゃないといけないんだけど、
オレオレOS作りたい奴がランタイム作ってて機能が肥大化してるのではないかと。
スケジューラが売りのようだが、ベアメタルではなくOS上で動かすのだから、無くてもOS側がそれなりにはやってくれる。
それをスケジューラ作りたいだけの奴が作っただけのように見える。
アプリを速くしたいのではなく、スケジューラを作り込みたいだけだから、チューニングが狂う。
この辺、JSはエンジン内の仕組みなんて誰も評価しないでしょ。
速いか遅いかだけ。だからチューニングが狂わない。

**デフォルトの名無しさん** · 2022/03/02(水) 01:42:28.65

OSがそれなりにさばかないよ。グリーンスレッドの価値を全否定だな。

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

**デフォルトの名無しさん** · 2022/03/02(水) 03:09:53.11

https://jsfiddle.net/z1bvwt3L/1/
1:1スレッドでのC++/Rustの結果も併記した(Rustのバージョンは1.58.1)
標準機能で記述する縛りでロジックだけ同じにすると現状ではこうだということ
M:NをC++/Rustで自前準備すれば別の比較ができるかもね

**デフォルトの名無しさん** · 2022/03/02(水) 03:13:52.18

あ、C++はgcc9.3、C++14で記述。

**デフォルトの名無しさん** · 2022/03/02(水) 03:34:51.80

>>55
全く意味のない比較になっている
Goではm:nグリーンスレッド利用
C++とRusyでは1:1つまりOSスレッド利用
ちゃんと3者ともにm:nグリーンスレッド利用で比較しなさい

**デフォルトの名無しさん** · 2022/03/02(水) 04:07:09.47

>>57
「標準機能で記述する縛りでロジックだけ同じ」という条件だとそれは無理な相談
むしろm:nでないとならない条件では成立しない

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

**デフォルトの名無しさん** · 2022/03/02(水) 06:39:48.32

Rustの標準ライブラリはunsafeのオンパレードだなｗ

**デフォルトの名無しさん** · 2022/03/02(水) 06:40:13.75

誤爆

**デフォルトの名無しさん** · 2022/03/02(水) 07:09:40.23

ライブラリもOS機能を使うならunsafeも致し方ないのではないだろうか、と誤爆にレス

**デフォルトの名無しさん** · 2022/03/02(水) 08:03:15.38

興味があるならどこの誤爆かだけ書いておく
https://mevius.5ch.net/test/read.cgi/tech/1638086359/447

**デフォルトの名無しさん** · 2022/03/02(水) 09:14:57.44

>>58
わざわざGoスレでくだ巻いてる方がやれよ。
できなけりゃGoを使うよ。

**デフォルトの名無しさん** · 2022/03/02(水) 12:54:03.99

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

**デフォルトの名無しさん** · 2022/03/02(水) 14:10:00.74

>>64
m:nとなるgoroutineを用いたGoと
1:1となるOSスレッドだけを用いたC++&Rustを比較することは無意味
比較したいならばC++&Rust側でもm:nでやりなさい

**デフォルトの名無しさん** · 2022/03/02(水) 15:24:10.33

>>64
勝ち負けを認めさせたいから言ったのでは無く、それ以上はRustスレでやれと言ってる。

**デフォルトの名無しさん** · 2022/03/02(水) 16:34:57.55

>>66
俺に言うなよ
>>65に言え

**デフォルトの名無しさん** · 2022/03/02(水) 16:54:30.69

C++スレでもRustスレでもここでも同じで無意味
m:nとなるgoroutineを用いたGoと
1:1となるOSスレッドだけを用いたC++&Rustを比較することはナンセンス

**デフォルトの名無しさん** · 2022/03/02(水) 17:04:08.05

thread単品で制御できないgoじゃこういう計測ができないのも理解できないとは・・・
何しにgoスレに来てるのやら

**デフォルトの名無しさん** · 2022/03/02(水) 17:33:02.75

C++とRustでもOSスレッドではなくm:nグリーンスレッドを使えばよいだけだろ

**デフォルトの名無しさん** · 2022/03/02(水) 23:43:26.42

>>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のは遅い、というより動くようにしか出来てない。（そして非同期）
だからそこそこ速い同期チャネルが絶対不可欠なアプリがあれば、と思って考えてみたが、やっぱり俺は思いつかないね。

**デフォルトの名無しさん** · 2022/03/03(木) 00:21:30.68

やり方がわからんのだろ。

**デフォルトの名無しさん** · 2022/03/03(木) 00:23:05.45

チャンネルが同期なのはバッファが無いとき
お前は本当に人な話を聞かないし何も読まないな。

**デフォルトの名無しさん** · 2022/03/03(木) 00:56:08.72

>>71
> 妥当性がどうのこうのは「GoランタイムのG実装」であって、君のデータについてではない。
うん、それは分かってたんだけど、定量的なデータがないとその妥当性分からんでしょ
M:Nのgoroutineだからと言って調子に乗って1:1の10倍積むと、俺の環境だとrssは超えてしまうってことがデータから分かる
データは簡単に取れる状況だったから、取っただけ

**デフォルトの名無しさん** · 2022/03/03(木) 11:28:44.36

Windowsでアップデート後にVScodeでテストを走らせると1.14.13でコンパイルされてるためツールバージョン1.17.7とマッチしませんと言われる
setting.jsonでgo.gopathを環境変数のGOPATHに合わせてビルドしてもダメ
かといってアップデートされたディレクトリを指定してもダメ

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

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

**デフォルトの名無しさん** · 2022/03/03(木) 11:44:33.79

いや…落ち着いてエラーログを見たら、例えばruntime/internal/sysが、とか言ってる
参照モジュール？

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

**デフォルトの名無しさん** · 2022/03/03(木) 13:27:09.03

とりあえず全部をアップデート先に統合する方向で納めた
バージョン混在状態だとどうしたらベストなのだろう？
環境的には最新に統合してgo.modでのバージョン記述に頼ればいい？

**デフォルトの名無しさん** · 2022/03/03(木) 18:20:17.50

>>74
つまりリソース的にGoroutineはOSのスレッドの数倍しか立ち上げられないということ？

**デフォルトの名無しさん** · 2022/03/03(木) 18:47:19.32

https://zenn.dev/mattn/articles/c453f42393778a
numpy より速い？Go の行列演算ライブラリ nune

やっぱＧＯは速いね

**デフォルトの名無しさん** · 2022/03/03(木) 20:31:53.54

>>74
それはご丁寧にどうも。ついでなら、
> C++は20を使えば標準機能だけで実装できるはず (>>58)
これについてもキーワードかURLだけでも教えてくれれば助かる。見に行く。
greenthreadが採用されたって事か？
(C++の場合は『全部入り』を目指してるからいつかは入るとは思うが）

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

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

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

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

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

**デフォルトの名無しさん** · 2022/03/03(木) 20:56:08.85

>>80
coroutine

**デフォルトの名無しさん** · 2022/03/03(木) 21:23:47.28

>>81
あ、そういう事ですか、なるほど。

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

**デフォルトの名無しさん** · 2022/03/03(木) 21:54:21.27

Docker CLIのダウンロードみたいな
複数のプログレスバーを出せるライブラリほしい
何がおすすめ？

**デフォルトの名無しさん** · 2022/03/03(木) 22:06:45.01

GUIなぞ基本的には管轄外です
お引き取りを

**デフォルトの名無しさん** · 2022/03/03(木) 22:22:12.59

CLIでのプログレスバーの話だろ？

**デフォルトの名無しさん** · 2022/03/03(木) 22:27:14.50

あーすまん

**デフォルトの名無しさん** · 2022/03/03(木) 23:09:26.23

いいってことよ

**デフォルトの名無しさん** · 2022/03/03(木) 23:29:47.34

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

**デフォルトの名無しさん** · 2022/03/03(木) 23:35:59.34

rustはもう少し標準ライブラリにも機能増やして欲しい。

**デフォルトの名無しさん** · 2022/03/04(金) 00:05:33.31

>>88
俺が依頼してる話でもないから俺に聞かれても・・・ではある。そもそもここgoスレだし何のためにそれをしたいのかすら分からない。

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

**デフォルトの名無しさん** · 2022/03/04(金) 07:00:31.23

非同期処理ですら紛糾して仕上がったのが2019/11な赤ん坊に無茶言うなって
Rustのコンセプトは分かるけど、学習難易度とライブラリの貧困さを何とかしないと浮かばれずにいつの間にか沈むぞ

**デフォルトの名無しさん** · 2022/03/04(金) 11:17:26.10

そんなにライブラリ貧困なの？
おれもまだ勉強中なんだけど何のライブラリで困るのか具体的に教えてくれ
勉強がてら試しに作ってみるかも

**デフォルトの名無しさん** · 2022/03/04(金) 13:21:46.53

>>91
学習難易度はキノコードが動画作れば解決w

**デフォルトの名無しさん** · 2022/03/04(金) 15:27:21.82

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

**デフォルトの名無しさん** · 2022/03/04(金) 15:37:03.27

>>92
むしろRustは民主主義方式なのでライブラリは多種多様に豊富
異なる考え方で作られたものが両立している分野もあるし後から優れたものが出てきてシェア拡大も起きたりしている
代わりに標準ライブラリ(std)は必要最小限のものしかなく
その一部であるコア標準ライブラリ(core)はヒープがなくても動作する更なる最小セットを提供

**デフォルトの名無しさん** · 2022/03/04(金) 15:39:19.04

間違ってる上にスレ違いすぎるな

言語比較がしたいなら↓へ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

**デフォルトの名無しさん** · 2022/03/04(金) 15:48:00.84

>>96
間違ったことは書いていない
質問や話題があったからそれに対して答えたまで

**デフォルトの名無しさん** · 2022/03/04(金) 15:52:46.98

>>97
>>96

**デフォルトの名無しさん** · 2022/03/04(金) 16:07:29.53

>>95
民主主義方式はc++みたいに標準委員会方式の場合だろ。
実装複数でデファクトスタンダードを競わせるってのは戦国時代方式だよ。

**デフォルトの名無しさん** · 2022/03/04(金) 16:41:14.71

>>99
あの標準委員会方式は強いて言えば一党独裁制だが紛糾ちぐはぐに近い
そしてC++の標準拡張が失敗してきた歴史を見ても反面教師としたのは理解できる

**デフォルトの名無しさん** · 2022/03/04(金) 17:03:59.90

>>100
>>96

**デフォルトの名無しさん** · 2022/03/04(金) 17:23:53.33

確かに、いい加減Goの話に戻そう。

**デフォルトの名無しさん** · 2022/03/04(金) 18:00:31.30

>>102
荒らしに荒さないでって言ってるようなもんだぞ
話が通じる相手ならとっくにやめてるだろ
相手にせずにNGなどで無視したほうがいい

**デフォルトの名無しさん** · 2022/03/04(金) 18:09:02.15

>>103
>>96

**デフォルトの名無しさん** · 2022/03/04(金) 18:20:16.68

そうだね
じゃあ 1.18 の話でもしよう

せっかく Generics が入るみたいのに、slice での Map、Reduce、Filter みたいなユーティリティが提供されないっぽいよね？
今はとりあえず準標準といえるものがこれ https://pkg.go.dev/golang.org/x/exp/slices
だと思うんだけど、そのうち増えるのかな？

例えばこんな感じの実装↓でいいと思うんだけど、本家でなんか議論されてるん？ Go追いかけてるひとおせーて！
https://gotipplay.golang.org/p/Y2cpCCPjKqr

**デフォルトの名無しさん** · 2022/03/04(金) 18:21:39.81

他のインタフェースが検討されてるとしたら、メソッドチェーンできるようにしたい、とかかな？

**デフォルトの名無しさん** · 2022/03/04(金) 19:18:02.80

Rustに移行すべきでは？

**デフォルトの名無しさん** · 2022/03/04(金) 19:23:47.26

>>107
>>96

**デフォルトの名無しさん** · 2022/03/04(金) 19:26:20.71

GoスレでRustRust言う奴から得るもんは何もない
失せろ

**デフォルトの名無しさん** · 2022/03/04(金) 19:27:58.27

>>106
メソッドチェーンの途中で>>105の実装のように毎回スライスを生成するのは無駄で遅いから
各メソッドをイテレータとして実装して中間生成物を作らないようにすべきかな

**デフォルトの名無しさん** · 2022/03/04(金) 19:30:36.16

たしかに効率的にするならイテレータにしないとね
それで簡単に仕様が決まらんのかな

**デフォルトの名無しさん** · 2022/03/04(金) 19:41:10.06

今一番rustの話で盛り上がるのがこのスレだからな

**デフォルトの名無しさん** · 2022/03/04(金) 20:33:03.39

Rust スレはどうなっているんだｗ

**デフォルトの名無しさん** · 2022/03/04(金) 20:34:31.83

NGword: Rust
なんでこれしないのか？

**デフォルトの名無しさん** · 2022/03/04(金) 20:36:30.45

>>113
Tauriで盛り上がってる
electronをRustで実装しなおしたら性能上がりすぎRust覇権とかwww
馬鹿だね～

**デフォルトの名無しさん** · 2022/03/04(金) 20:41:31.76

>>110
それ7年前のRust 1.0公開時からサポートしてる機能だが
Rustはプル型にすることで無駄な動きをゼロにしつつメソッドチェーンの形になってもヒープを使わずスタック上のみで動く特徴がある
しかしGoでは受け入れられる方針なのだろうか？
一方でプッシュ型であるチャネルを使った実装だとプッシュ型にすることでのムダよりもgoroutineを使うオーバーヘッドが大きい

**デフォルトの名無しさん** · 2022/03/06(日) 19:22:52.31

>>40
そのとおり。
決定的なのは、goをRustで実装してしまえばいいw
それがすべてだろw逆にRustをgoで実装することは何万年立っても不可能なんだからw
なぜならgcのある言語でgcのない言語を実装できないから

**デフォルトの名無しさん** · 2022/03/06(日) 19:40:37.34

Istioがまさにそうだよ
> RustをGoで実装

**デフォルトの名無しさん** · 2022/03/06(日) 21:05:29.02

フリーランスだけど未経験OKのところに応募してみた。
採用されたらよろしくな。

**デフォルトの名無しさん** · 2022/03/06(日) 21:06:19.97

>>117
なんでだよw
言語処理系にGCがあるかないかと、それから作られるバイナリにGCがあるかないかなんか関係ないだろwwww
インタプリタじゃあるまいし。

**デフォルトの名無しさん** · 2022/03/06(日) 23:38:19.72

>>117
コンパイラの処理って何か知ってる？

**デフォルトの名無しさん** · 2022/03/07(月) 00:39:41.57

>>117
あのーGoもRustも最終的に吐き出すのは機械語のコードだよ？
その場合GCはランタイムに含まれるんですがそれは実装する言語関係ないですよ？

**デフォルトの名無しさん** · 2022/03/07(月) 00:44:33.34

>>122
goでメモリ管理まで書くの？そしたら所有権とかの概念があるRustに軍配があがるだろ