Go language part 4

**デフォルトの名無しさん** · 2020/11/16(月) 04:14:40.64

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

公式
https://golang.org

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

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

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

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

**デフォルトの名無しさん** · 2022/02/25(金) 21:35:23.89

このおじさん勢いあるスレならどこにでも湧くな

**デフォルトの名無しさん** · 2022/02/25(金) 21:47:06.20

こんなおじさん昔はいなかったのにどこから湧いてきたんだろう

**デフォルトの名無しさん** · 2022/02/25(金) 21:57:26.52

退職してすること無くて暇なんじゃね？

**デフォルトの名無しさん** · 2022/02/25(金) 22:05:54.67

観察者効果で生まれた

**デフォルトの名無しさん** · 2022/02/25(金) 22:10:44.84

そのおじさん昔からいるぞ
昔はコテハンも使ってたが相手にされなくなったてやめたみたい
Ruby君と並ぶ有名人

**デフォルトの名無しさん** · 2022/02/25(金) 22:50:23.56

>>925
RustスレはRustそのものの議論をするスレだから他言語との比較はやらないだろ
↓こっちのスレの方に行ってもらったほうがいいと思う。
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

もしくは↓このスレがあるんだったら
C vs C++ vs Rust Part.3

golang vs Rust Part.1
みたいなスレを作るとか

**デフォルトの名無しさん** · 2022/02/25(金) 22:52:44.27

Rust vs その他
みたいなスレにまとめてくれ

**デフォルトの名無しさん** · 2022/02/26(土) 01:11:35.81

>>915
> だから「Rustが1番、Goが2番、でも書きやすいからGoを使う」という発想がおかしい。
この発想は俺は別におかしいとは思ってない。
例えばアメリカでは「Pythonで書け」と言われるらしいが、これは、
「Pythonは糞だが誰でも読める。前任者がいなくなっても後任者がすぐ見つかる」からであり、
自分個人で完結する物以外は言語特性や好みだけで選べるものでもない。
だからWeb系なら「とりあえずJS/TSで書け」となるのが妥当、という話はすでに788でした通り。
が、まあ、これはさておき、

> 「この案件にはGoが1番良い」という発想でGoを選定するんよ。
だからこれは何なんだよ？という話だろ。Web系ではない、というか、
TS/Node/Rustが出てきた時点でWeb系に最適な解ではなくなったというのは792,857で言ったとおり。

> プログラミングのパラダイムとしてのasyncであれば、
> goは同期関数のように書いてもほぼ全ての行に対してasync/awaitだよ。それがgoroutineなんよ。
これは言いすぎだが、goroutineでasyncの代替になるのは事実だ。
ただ、そういう書き方って基本的にしてないでしょ。
多くの人はマルチスレッドだと思って書いてるし、Goの公式ドキュメントもそうだったと思ったが。
(goroutineは非同期を実現するための物です！！！なんて謳ってたっけ？)

マルチスレッド：同期関数を実行するスレッドが沢山。
　単に高火力を必要とするならスレッドを複数起動して既にあるコードをぶち込めばOK。
非同期：非同期ジョブは『どの順で完了しても』問題なく動くように書く必要があり、
　また、非同期ジョブの実行順/完了順の指定も出来ない。
　（だから数珠繋ぎにするしかなく、コールバック地獄だPromiseだ、という話になる）

だから非同期の場合は根本的にマルチスレッドとはプログラミングを変える必要があって、
具体的にはイベントドリブンで書く事になる。だからJSにはmainがない。
ところがGUIもイベントドリブンで書くので、元々GUI担当のJSとは相性がいい。
（というか、だから当時は異端でしかない「非同期」を採用したのかもしれないが）

**デフォルトの名無しさん** · 2022/02/26(土) 01:11:53.09

逆にmainがあるのは、
mainから入って、高火力が必要ならスレッド起動で同じコードを走行させる、という
マルチスレッドのパラダイムに適した構造だ。
だからmainがある言語、例えばCでGUIを書くと悲惨なコードになる。元々イベントドリブン向きに出来てないからだ。
Goも同じで、基本的にはfork/joinを完結にgoroutineで出来るようにしてるだけで、それはマルチスレッド向けだよ。

つっても非同期スタイルで書けば書けるのも事実だけどな。
819のベンチでGoはAsynchronousTCPとなってるが、これはそういう事なのかね？
なおNode(multithread)に1.5倍も負けてるのは、多分ランタイムの問題だよ。
JSは非同期専用のランタイムであり、それに対してマルチスレッド向けのランタイムに非同期コードを載せて非同期にしたくらいでは並べない。
というか、静的コンパイル言語がJITとはいえ動的言語に大差で負けてる事自体があり得ない事で、
これは「同じ土俵で戦えていない」事を意味する。一つはランタイムで、本来は、
・精々マシンスレッドと同程度～数倍程度のgoroutine用
・マシンスレッドの100-1000倍以上程度のgoroutine用
・非同期コード用
とチューニングや内部構造を変えたランタイムを用意すべきだよ。
資産はコードであり、ランタイムは交換すればいいだけなので、やればいいだけだと思うのだけど。（もうやってるかもしれないが）

あとついでに言うと、ランタイムはやっぱりC/C++で書くべきだよ。境界チェックを遅くなる言い訳にするのなら特に。
Go/Rust共に、「これでCのコードはなくなりました！えっへん！」ってな事をやってたと思ったが、
ランタイムが遅いようでは勝負にならないからね。
「GoをメンテするためにはGoだけ知っていれば十分で、Cを知っている必要はない」ってのはコミュニティの宗教として重要なのは分かるけども、
実用性を考えたら、ランタイムなんて糞速い事が重要であって、何言語だっていいでしょ。
この辺、スクリプト言語はDSLだとわきまえてて、ランタイムを自言語で書こうとかいう無駄な事をやってない。

**デフォルトの名無しさん** · 2022/02/26(土) 01:13:02.46

> そしてasync/await・Promise以前のtry-catchは使い物になりません。
これは言いすぎ。try-catchはろくでもないが、無いよりはましだし、同期でシングルデータならまあ問題ない。
だからGoもtry-catchでも良かったはずだが、採用してないところを見ると、
「多くの場合はtry-catchがgoroutineを跨いで使い物にならない」と思ったのだろう。
ゆうてもGo流の多値返しはCよりはまし程度で、それ以上でもないが。

ただ、try-catchがgoroutineを跨ぐ想定なら、
メインスレッドが仕事を起動し、各goroutineで子細の処理をこなす、マルチスレッドの構造を想定している。
非同期なら、メインスレッドはイベントループだけを担い、手が空いたgoroutineにその都度ジョブを発給する事になるけども、
この場合はジョブの起動はgoroutine内からで、try-catchは完全に機能する。
JSの場合はI/Oを非同期にする事を義務づけらてるからtry-catch内にI/Oが入った時点で意味を為さないし、大体このパターンだが、
Goの場合はI/Oも同期で書けるのだから、全く問題ない。
だからやっぱり元々の想定はマルチスレッドで、文法的には非同期も特に苦労せずに書ける、ってことだと思うのだけど。
(JS的な全面的非同期を想定していた場合は、try-catchを不採用にする理由がない。当時でも既にtry-catchが主流だった）

>>917
> RustはGoと同じくtry-catchを採用していないね
これ、今見たところPanic方式らしいが、もしかしてGo由来？

try-catchは好きな人は大好きのようだが、俺にはどうにもあれがいいとは思えない。
個人的には、リソース返却ならC#のusingが正解で、
リトライなら、大体元データが壊れてて無理で諦めるのでPanicで問題ない。（エラー通知だけ出来れば十分）
だからtry-catchは非同期では使えない過去の異物として消滅して欲しかったのだけど、
C#がasyncでも無理矢理try-catch出来るようにしたのでちょっと驚いてる。
そこまでしてtry-catchしたくもないし、する内容もないんですけど、ってね。
ある意味JSの「catchなんてしなくても何も問題ないです」というJavaから見れば卒倒しそうな仕様も、解の一つではあると見てる。

**デフォルトの名無しさん** · 2022/02/26(土) 06:42:38.06

>>937
JavaScriptの非同期呼び出しでも普通は無視せずPromiseにcatch付けて捕獲するぜ
例: async_func_foo.catch(err => console.log(err))
あとRustの非同期呼び出しもResultが帰ってくるからエラーを捕獲できる

**デフォルトの名無しさん** · 2022/02/26(土) 07:29:58.26

Goを叩く為にJavaScriptを使ってるだけで、JavaScriptの理解度かなり浅いなこのおじさん。
しかしこんなおじさんがずっと暴れてんのか、全然議論できないじゃん。対策としてはワッチョイ導入くらいしか無いだろうね。

**デフォルトの名無しさん** · 2022/02/26(土) 08:20:49.61

長い文章ダラダラ書く人ってプログラマーの素質ないよ
文章を短く簡潔に書ける人ってプログラムも同様に書ける

**デフォルトの名無しさん** · 2022/02/26(土) 08:45:19.95

>>938
> 例: async_func_foo.catch(err => console.log(err))
これは字が赤いか黒いかの違いしかないけどな。

まあ俺はtry-catch消極派だから、Go/Rust方式で問題なく、C#の仕様はオーバースペック過ぎるけど、
Goの場合はJSとは違ってtry-catchはそれなりに機能するはずだから、不満持ってる奴もそれなりにいるはずだけど。
（そういう連中は既に去ってる気もするが）

**デフォルトの名無しさん** · 2022/02/26(土) 09:09:48.94

発想が違う、どの案件でも、その案件にとって1番だから使う、と言う言葉が伝わってないのか？
俺も十分、言外の言葉は理解できないタイプだが、流石に通じると思うんだが。

書きやすい、読みやすいからこれを選定した、と言うのは「1番」でしょ。

基本的にそういう書き方してると言うか、自然に書くとそうなる。これはドキュメントに書いてあっただろ。

非同期とマルチスレッドを分けて考えろよ…。

実際にはnodeもそうだけど、C#のTaskなんかに関してもめちゃくちゃ解像度甘いのでは？

**デフォルトの名無しさん** · 2022/02/26(土) 09:10:48.16

goだと、非同期スタイルで書けるとかでなくて、ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。常に低コストで。
それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。

**デフォルトの名無しさん** · 2022/02/26(土) 09:11:12.66

オール想像で喋ってるよな、こいつ。

**デフォルトの名無しさん** · 2022/02/26(土) 09:42:59.75

>>939
ワッチョイは浪人生の自演が捗るだけ

**デフォルトの名無しさん** · 2022/02/26(土) 09:45:22.81

ローニンでワッチョイ消してるやつ正規表現で弾けばええやん

**デフォルトの名無しさん** · 2022/02/26(土) 09:55:57.50

自演するのにワッチョイ消すバカはおらんやろ

**デフォルトの名無しさん** · 2022/02/26(土) 10:07:05.87

荒らしの手間が増えるだけで十分価値がある

**デフォルトの名無しさん** · 2022/02/26(土) 10:19:30.57

>>943
> ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。
これは普通はマルチスレッドと言う。Thread/goroutineを複数（マルチ）起動して引っかかったらスイッチングさせるだけなのだから。
そして大概の言語はこれを自然に書けるようになってる。

> それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上
これが嘘、というか誤解。他言語でもいくらでもスレッドを起動する事は出来る。（が余計に重くなるので普通はやらない）
goroutineもGo信者が言う程軽くもないのでいくらでも起動していいわけではない。(現実的には)

これを脳死でgoroutineはコストゼロ、だからgoroutineに切り出す事がプログラマの仕事である、と解釈できれば美しいのだが、
これを実際に試して「思ってたよりも全然パフォーマンスが出ねぇ、これならNodeの方が速ぇ…」となった顛末を書いてたのが何度も言ってるブログ。
これは言語と言うよりはランタイムの問題だけど。

**デフォルトの名無しさん** · 2022/02/26(土) 11:28:52.99

JSのPromiseは非同期の扱いとしてはかなり好き

**デフォルトの名無しさん** · 2022/02/26(土) 12:15:41.10

>>949
N:Mのグリーンスレッドであって単なるマルチスレッドじゃない。
単に引っかかったら切り替えるんでなくてスティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。

どこが嘘なんよ。
コストゼロでは無いが、いわゆるスレッドよりは遥かに軽いぞ。

**デフォルトの名無しさん** · 2022/02/26(土) 12:16:18.51

総じて知らんだけでは？

**デフォルトの名無しさん** · 2022/02/26(土) 12:35:54.23

わからせようとするのが無駄だって何で気づかないかな

**デフォルトの名無しさん** · 2022/02/26(土) 12:41:19.24

>>940
論理構成がしっかりしてて読みやすければ長文でもいいんだけどね
このおじさんはそこが壊滅的だから明らかに素質ないわな

**デフォルトの名無しさん** · 2022/02/26(土) 12:50:12.55

抽象化できず同じ事何回も書く傾向にあるから、凄いコード書きそう

**デフォルトの名無しさん** · 2022/02/26(土) 12:58:01.48

>>955
というか、
短い=良い
もしくは
simple=beautiful
というセンスが欠落している。
あんな汚い長文ぞっとするわw
まあ.{50}でNGにしてるけど

**デフォルトの名無しさん** · 2022/02/26(土) 13:27:19.11

Goの(疑似スレッド＋)goroutineのパフォーマンス計測っていいやつないの？
↓見つけたやつ
Goroutines Are Not Significantly Smaller Than Threads
https://matklad.github.io//2021/03/12/goroutines-are-not-significantly-smaller-than-threads.html

**デフォルトの名無しさん** · 2022/02/26(土) 13:41:54.09

Goってぶっちゃけ言語機能とか割とどうでもよくて、
・ビルドやデプロイや運用がシンプル
・本家の開発体制が保守的で、長期的に安定したサポートが期待できる
という点がメリット
極力作りっぱなしで放置したい類のものに向いてると思うんだよね
Goしかできない奴やGo大好きで使ってる奴もまずいないだろうし、こんなもん執拗に叩いて何がしたいの

**デフォルトの名無しさん** · 2022/02/26(土) 13:51:01.17

CLIツールはともかく一番使われてるWeb APIは放置したいものとは対極だろう

**デフォルトの名無しさん** · 2022/02/26(土) 14:05:08.22

APIはむしろどっちかというと放置したい系じゃね？
フロントと表裏一体みたいなのもあるけど、そういうのにGoはあまり採用されないでしょ

**デフォルトの名無しさん** · 2022/02/26(土) 14:21:48.69

確かにそうだな。わかろうとしないし、伝わらない気がしてきた。
Rust最高とRustスレで言っててくれれば良いか。

>>958
これはあるよね。
1つ前のバージョンどころか、それなりに昔のGoのプログラムですら修正せずにコンパイルできる。

**デフォルトの名無しさん** · 2022/02/26(土) 16:17:55.72

>>951
やってないのはやる必要がないから。
他言語も馬鹿ではないので、改善の努力はしてるし、いい点があったら平気でパクってる。

(Goはgreenthreadで全て解決！と謳っているわけではないけども、そうだとしたら）
そのアイデアは面白かったが、現実的ではなかった。
（ただしこれはランタイムの問題だから改善の余地はあるはず）

非同期はコードがうざくなるのは事実だが、async文法でほぼ払拭された。
だからみんなパクってる。

まあ完全にループだし、材料枯渇でここら辺で終わりかな。
そりゃ信者の念仏を何度聞いても翻意する事はないよ。俺は文系ではないし。
こちらの見解では説明出来ないデータが出て来たら、分析して、考えを修正するけど。

>>957
virtualの40MBを単純に合算したら、今は4倍軽くて、4k/goroutine時代は2.5倍軽かったという事か。
フットプリントだけの比較ではあるが。
だから極めて単純に言えば、他言語のスレッドでジョブを4つずつ束ねて処理する運用をすれば、
フットプリントでは並んで、速度は余分なスケジューラが入ってない分勝てる事になる。

**デフォルトの名無しさん** · 2022/02/26(土) 17:32:36.09

>>960
そりゃWebのフロントエンドに比べりゃなんだって放置したい系になるだろ
Webの場合はバックエンドでもWebフレームワークをサポートバージョンに維持する必要があるから
長くても3〜5年すればコードを変更することになる

**デフォルトの名無しさん** · 2022/02/26(土) 17:33:24.82

>>958
言語機能は本当に20世紀に設計された言語なのかと
疑いたくなるね
ほぼGCがあるCを書いてる感覚に近い
C書けない人が書ける言語じゃないと思う

**デフォルトの名無しさん** · 2022/02/26(土) 18:00:31.99

>>962
はい、じゃあ言質も取れたのでRustスレに戻って下さいね

**デフォルトの名無しさん** · 2022/02/26(土) 18:06:45.33

>>963
そうか？コアAPIに関してはあんまり手を入れないけどな。
Webフレームワーク次第なAPIってどんなの？

**デフォルトの名無しさん** · 2022/02/26(土) 18:16:48.89

>>966
SPAのすぐ裏でUIの要件に合わせて作るようなやつのことじゃね？
そういうのはそもそもGoを採用しないと>>960で書いた通りだ

**デフォルトの名無しさん** · 2022/02/26(土) 19:00:50.19

>>967
なるほど。BFF的なやつ。
たしかにGoで書くまでもないし、ノンコーディングもあるよね。

**デフォルトの名無しさん** · 2022/02/26(土) 19:13:38.66

正直なんだかんだ言って、学習コストに対しての性能パフォーマンスが異様に高いというところがGoの魅力
言語仕様がコンパクトだからミスしにくい(気がする)のも良い
チャネルに容量があることを忘れるうっかりさん以外には

得意な機能は限られててGUIとかは苦手だけど、そんなもんC#やらに任せとけばいいや

**デフォルトの名無しさん** · 2022/02/26(土) 19:41:27.25

Goの魅力はケン・トンプソンなんよ

https://en.wikipedia.org/wiki/Ken_Thompson#2000s
> When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research.
> The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,]
> we started off with the idea that all three of us had to be talked into every feature in the language,
> so there was no extraneous garbage put into the language for any reason.

彼が"we hated C++"つって作っただからそらもうみんな嬉しいやろ

**デフォルトの名無しさん** · 2022/02/26(土) 19:44:13.98

結局>>957よりいいパフォーマンス計測ってないのかー
個人的感想としては。。。
パフォーマンスについて特筆すべき利点はない
原理的にスレッドプールを使った他言語のコードと同程度の性能が出る
機能的な利点はグリーンスレッドを言語で持っており、自動でOSスレッドと使い分けられる点(記述量低＆必要メモリ低)
逆に欠点はスケジュールをコントロールする方法がGOMAXPROCS以外ない点ってところかな

**デフォルトの名無しさん** · 2022/02/26(土) 20:07:50.21

>>971
優先度がないのはちょっぴり残念ではある
…ないよね？

**デフォルトの名無しさん** · 2022/02/26(土) 20:31:14.25

>>969
> 学習コストに対しての性能パフォーマンスが異様に高い
Cの方が高いけどな。Goよりも小さい仕様で速い。
あとC#もGUIはゴミだぞ。それ以外がいいからunityを制覇してるが。

**デフォルトの名無しさん** · 2022/02/26(土) 21:20:48.95

>>943
>> それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。

RustもM:Nモデルだよ
Goと同じく複数の非同期タスクを複数のOSスレッドに割り当て
しかもGoとは異なりスタックレスなのでGoよりも軽量タスクを実現しているよ

>>951
>> スティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。

RustもGoと同じM:Nモデルでワークスティーリングもしているよ
Rustでは以下のランタイムを選ぶことができるよ
・1:1モデル (＝M:Mモデル、OSスレッドそのまま利用)
・M:1モデル (シングルOSスレッドで並行マルチタスク)
・M:Nモデル[スレッドプール方式]
・M:Nモデル[ワークスティーリング方式]

**デフォルトの名無しさん** · 2022/02/26(土) 21:35:40.76

>>974
それは処理系標準？それとも準標準？

**デフォルトの名無しさん** · 2022/02/26(土) 21:58:06.53

>>974
それ以下と定義が同じだと、一般的には「ワークスティーリング方式」を「スレッドプール」と呼称するよ。（だからC#のもこれのはずだけど）
https://tech-blog.optim.co.jp/entry/2019/11/08/163000
Rustで何故あえて方言にしているのかは知らん。
というかワークスティーリングじゃない方のメリットなんてない気がするんだが。

**デフォルトの名無しさん** · 2022/02/26(土) 21:58:10.74

>RustもGoと同じM:Nモデルでワークスティーリングもしているよ

VMじゃないのにどうやって実現してるのかな

**デフォルトの名無しさん** · 2022/02/26(土) 21:59:12.46

>>975
RustはGoと真逆で標準ライブラリとは最小限のものに限る位置付けなので
標準ライブラリには非同期ランタイムを作るための枠組みだけが存在していてランタイム自体は無しだよ
これは全ての分野について同じ方針でRustでは標準＋準標準(デファクトスタンダード)を使ってプログラミングをするよ

**デフォルトの名無しさん** · 2022/02/26(土) 22:13:34.76

>>976
そこは一般的は話としてまずOSスレッド毎にキューと持つかグローバルにキューを持って割り振るかの2大方式があるよ
それぞれに利点と欠点があってそこは省略するけど
GoもRustもそのハイブリッド方式となっていて普段はスレッド毎にキューを持って各OSスレッドが独立に効率よく処理だね
そしてGoもRustもグローバルにも管理して暇なOSスレッドが生じるとそこへ割り振る(OSスレッドから見るとスティール)するよ
詳細はここで書ききれないほどもう少し複雑だから省略してる点はそれぞれの解説サイトなどを見てね

**デフォルトの名無しさん** · 2022/02/26(土) 22:54:22.46

>>979
Goと同じなら805のリンクの内容と同じだからああそうですか程度。
資料が古いがC#のは以下で確認した。同様にハイブリッドでスティーリングもあり。
（ただ.NET6.0とかだともう変わってそうだが）
https://ufcpp.net/study/csharp/misc_task.html
基本グローバルキューで、ただし優先順位はローカルキュー＞スティーリング＞グローバルキューになってる。
この構造はまあ納得。

> GoもRustもそのハイブリッド方式となっていて普段はスレッド毎にキューを持って各OSスレッドが独立に効率よく処理だね
> そしてGoもRustもグローバルにも管理して暇なOSスレッドが生じるとそこへ割り振る(OSスレッドから見るとスティール)するよ
無駄に複雑で余計に遅くなると思うけどね。.NETの方が単純ですっきりしてていい。
グローバルキューから取り出す時の競合を気にしてるのなら、
Goみたいに100,000goroutineとか目指す場合は分かるけど、Rustは基本そうじゃないだろうから、チューニングミスだと思うけど。

**デフォルトの名無しさん** · 2022/02/26(土) 23:02:07.46

Goは別に最速を目指している言語じゃないからね
もし何かのベンチマークが最速になってしまったら逆に驚くよ
そのベンチ間違ってるだろ、って。

**デフォルトの名無しさん** · 2022/02/26(土) 23:40:35.78

>>977
VMじゃないと起きる問題点は何？
いずれにせよC/C++/RustはVMでもOSでも記述できるのだからそこに不可能は無い

>>980
言語に関係なくシステムスレッド間のグローバルな操作はデータ競合回避など一定のコストがかかる
だから可能な限り個別にシステムスレッドが動くようにしつつアイドルが出ないよう最小限のグローバル操作
この部分はよほど上位で制約のある仕様としていないならば全ての言語で同じ

**デフォルトの名無しさん** · 2022/02/26(土) 23:48:39.58

>>978
これがなぁ…。過渡期は混ぜるな危険で困らない？そこが不安。
Rustも良いとは思うんだけど、爪切るのにハサミ使ってる気分になる。

**デフォルトの名無しさん** · 2022/02/26(土) 23:59:29.99

>>982
それはハードによる。
x86はハードウェアでキャッシュコヒーレンシを取ってくれるので実は共有RAMでもコストは安い。
.NETがローカルキューからの取り出しでFIFOとFILOで競合が減るから、というのはそういう事。
Goの場合はARMを見てるのか、MacがARMに乗り換える布石だったのか、
以前からやたら「共有RAMは遅いから使わない」としてきてるが、
ぶっちゃけx86の場合は
（書き込み頻度と量によるが、タスクの起動＝関数ポインタ１つと引数のポインタ程度なら）
OSを利用したチャネル接続よりも共有RAMの方が実は速い。
ここら辺を理解してない奴がグダグダやってるからチューニングし切れてないのだと思うよ。

**デフォルトの名無しさん** · 2022/02/26(土) 23:59:34.35

>>980
>> Goみたいに100,000goroutineとか目指す場合は分かるけど、Rustは基本そうじゃないだろうから、

Rustの非同期タスクはGoroutineよりも更に軽くて
Goとは異なりスタックレスなので付加メモリ消費も非同期ランタイムの管理データ分の1タスクあたり64bytesで済みますよ
そしてグローバルキュー競合コストの件は>>982のように同じですね

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

>>982
問題があると言っているわけじゃなくて、VMやOSじゃなければプリエンプションできないからどうやっているのかなと。

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

>>973
Cはお爺ちゃんだから…
Cからの乗り換えコストっていう視点でどうかひとつ

あ、でも実装系別の頭おかしくなるコンパイルオプションやらバウンダリやらのメモリモデル考えると、Goのほうが実質勝ってないか学習コスト？

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

>>973
ちなみに速さやらサイズでは当然にCとかの圧勝だろ普通に
関数呼び出しごとにオーバーヘッドのかかるGoが単純な速度で勝てる道理はない

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

>>973
C#というか.Netのwpfは好き
一般的な手法じゃないだろうけど、MVVMのVM部分を単体テストできて(ディスパッチャ細工してメインスレッドで走らせる)

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

>>985
> Goとは異なりスタックレスなので
やたらこれを強調しているが、goでもgoroutineにローカルキュー（＝関数ポインタの配列）を用意して、順に食わせれば、
各タスク毎にスタックを用意する必要なんて無くて、普通にエミュレーション出来るよ。
(ただしGo信者的にはこれは負けだからやらないとも思うが）

ただこの場合、各タスクが止まらない前提ならこれでいいが、
止めて切り替える分には一般的にはスタック領域が必要になる。
(自動変数を全部ヒープ上に確保すればスタック無しでもいいが、これは遅くなるので多分やってないと思う)
ユーザーが確保しなくていいだけで、実際はランタイムかコンパイラが確保してくれてるだけじゃないか？

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

>>988
> 関数呼び出しごとにオーバーヘッドのかかるGo
かからないような気がするが、自信はない。かかる理由って何？

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

>>991
Goは関数呼び出しごとにスタックをチェックして、不足してたなら拡大するから
関数ごとの静的な自動変数サイズと比較してるだけだと思うけど、そういう処理のおかげで初期スタックサイズを抑えてる
https://postd.cc/performance-without-the-event-loop/

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

>>991
「十分な空間がない場合、ランタイムはヒープに対して大きなスタックセグメントを割り当て、現在のスタックの内容を新しいセグメントにコピーし、古いセグメントを解放し、それから関数呼び出しを再開します。」

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

>>991
毎回拡張する訳じゃないけどそのためのチェックは毎回走るんで、単にサブルーチンを呼ぶだけの他言語よりは余分な仕事をしている
おそらくチェックは必要な回数だけだとは思う(ループ内での呼び出しとかの最適化は考えてないとは思わないから)

**デフォルトの名無しさん** · 2022/02/27(日) 06:52:35.32

compiler explorer(https://godbolt.org/)で、goコンパイル結果を普通のamd64用のアセンブラ見ること出来ないの？(Plan9でなく)

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

次スレ建ててくる

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

Go language part 5
https://mevius.5ch.net/test/read.cgi/tech/1645915400/

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

>>990
Rustの非同期タスクは内部的には単純な状態マシンとなり何度も再入可能なコルーチンと同じ状況になります
その中の変数はRustのクロージャがその環境の変数をキャプチャするのと同じだからもちろんメモリを確保します
だからスタックレスで何度も呼べるクロージャみたいな状況でスタック自体はプロセス全体で1本のままとなります
もちろんその非同期タスクから他の非同期でない普通の関数を呼べば通常と同じくスタックが伸びて使われていきます
一方でその非同期タスクから他の非同期な関数を呼ぶとその非同期タスクから一旦離脱してスケジューラーへ戻ります
最初に書いたように「単純な状態マシンとなり何度も再入可能なコルーチン」となっているので再び再開できます
以上がスタックレスなのにRustの非同期タスクがメモリの許す限り多く動くことができる仕組みです

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

ワッチョイ無しかー(´・ω・｀)

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

goroutineとC++標準ライブラリのスレッドを比較するために>>957のmain.rsのC++版だけ作ってみた(ループは一桁減らした)
$ cat main.cc
#include <thread>
#include <chrono>
#include <vector>
using namespace std;
using namespace std::chrono;
int main() {
vector<unique_ptr<thread>> threads;
for (uint32_t i = 0; i < 1000; ++i) {
threads.emplace_back(
make_unique<thread>([=]{
uint64_t bad_hash = (i * 2654435761) % 200000;
this_thread::sleep_for(microseconds(bad_hash));
for (uint32_t _ = 0; _ < 1000; ++_) {
this_thread::sleep_for(10ms);
}
})
);
}
for (auto const& t: threads) {
t->join();
}
return 0;
}
$ g++ -O3 -pthread main.cc -o main && ./t ./main
real 11.04s
user 0.93s
sys 2.95s
rss 11328k
$
結果はmain.rsとほぼ同じで、やはりスレッド起動コストがデカく、rssもデカい

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 468日 4時間 2分 1秒