[過去ﾛｸﾞ]
Go language part 4 (1002ﾚｽ)
Go language part 4 http://mevius.5ch.net/test/read.cgi/tech/1605467680/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
1: デフォルトの名無しさん [sage] 2020/11/16(月) 04:14:40 ID:fB5+0hxC 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/ http://mevius.5ch.net/test/read.cgi/tech/1605467680/1
978: デフォルトの名無しさん [sage] 2022/02/26(土) 21:59:12.46 ID:4mZJSMD8 >>975 RustはGoと真逆で標準ライブラリとは最小限のものに限る位置付けなので 標準ライブラリには非同期ランタイムを作るための枠組みだけが存在していてランタイム自体は無しだよ これは全ての分野について同じ方針でRustでは標準＋準標準(デファクトスタンダード)を使ってプログラミングをするよ http://mevius.5ch.net/test/read.cgi/tech/1605467680/978
979: デフォルトの名無しさん [sage] 2022/02/26(土) 22:13:34.76 ID:4mZJSMD8 >>976 そこは一般的は話としてまずOSスレッド毎にキューと持つかグローバルにキューを持って割り振るかの2大方式があるよ それぞれに利点と欠点があってそこは省略するけど GoもRustもそのハイブリッド方式となっていて普段はスレッド毎にキューを持って各OSスレッドが独立に効率よく処理だね そしてGoもRustもグローバルにも管理して暇なOSスレッドが生じるとそこへ割り振る(OSスレッドから見るとスティール)するよ 詳細はここで書ききれないほどもう少し複雑だから省略してる点はそれぞれの解説サイトなどを見てね http://mevius.5ch.net/test/read.cgi/tech/1605467680/979
980: デフォルトの名無しさん [sage] 2022/02/26(土) 22:54:22.46 ID:kpnhrKVl >>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は基本そうじゃないだろうから、チューニングミスだと思うけど。 http://mevius.5ch.net/test/read.cgi/tech/1605467680/980
981: デフォルトの名無しさん [sage] 2022/02/26(土) 23:02:07.46 ID:Gc6jVciw Goは別に最速を目指している言語じゃないからね もし何かのベンチマークが最速になってしまったら逆に驚くよ そのベンチ間違ってるだろ、って。 http://mevius.5ch.net/test/read.cgi/tech/1605467680/981
982: デフォルトの名無しさん [sage] 2022/02/26(土) 23:40:35.78 ID:BX4iLvdt >>977 VMじゃないと起きる問題点は何？ いずれにせよC/C++/RustはVMでもOSでも記述できるのだからそこに不可能は無い >>980 言語に関係なくシステムスレッド間のグローバルな操作はデータ競合回避など一定のコストがかかる だから可能な限り個別にシステムスレッドが動くようにしつつアイドルが出ないよう最小限のグローバル操作 この部分はよほど上位で制約のある仕様としていないならば全ての言語で同じ http://mevius.5ch.net/test/read.cgi/tech/1605467680/982
983: デフォルトの名無しさん [sage] 2022/02/26(土) 23:48:39.58 ID:yRlIqUsp >>978 これがなぁ…。過渡期は混ぜるな危険で困らない？そこが不安。 Rustも良いとは思うんだけど、爪切るのにハサミ使ってる気分になる。 http://mevius.5ch.net/test/read.cgi/tech/1605467680/983
984: デフォルトの名無しさん [sage] 2022/02/26(土) 23:59:29.99 ID:kpnhrKVl >>982 それはハードによる。 x86はハードウェアでキャッシュコヒーレンシを取ってくれるので実は共有RAMでもコストは安い。 .NETがローカルキューからの取り出しでFIFOとFILOで競合が減るから、というのはそういう事。 Goの場合はARMを見てるのか、MacがARMに乗り換える布石だったのか、 以前からやたら「共有RAMは遅いから使わない」としてきてるが、 ぶっちゃけx86の場合は （書き込み頻度と量によるが、タスクの起動＝関数ポインタ１つと引数のポインタ程度なら） OSを利用したチャネル接続よりも共有RAMの方が実は速い。 ここら辺を理解してない奴がグダグダやってるからチューニングし切れてないのだと思うよ。 http://mevius.5ch.net/test/read.cgi/tech/1605467680/984
985: デフォルトの名無しさん [sage] 2022/02/26(土) 23:59:34.35 ID:4mZJSMD8 >>980 >> Goみたいに100,000goroutineとか目指す場合は分かるけど、Rustは基本そうじゃないだろうから、 Rustの非同期タスクはGoroutineよりも更に軽くて Goとは異なりスタックレスなので付加メモリ消費も非同期ランタイムの管理データ分の1タスクあたり64bytesで済みますよ そしてグローバルキュー競合コストの件は>>982のように同じですね http://mevius.5ch.net/test/read.cgi/tech/1605467680/985
986: デフォルトの名無しさん [sage] 2022/02/27(日) 00:02:30.74 ID:2GGoVw4G >>982 問題があると言っているわけじゃなくて、VMやOSじゃなければプリエンプションできないからどうやっているのかなと。 http://mevius.5ch.net/test/read.cgi/tech/1605467680/986
987: デフォルトの名無しさん [sage] 2022/02/27(日) 00:03:38.38 ID:uWHjNeVw >>973 Cはお爺ちゃんだから… Cからの乗り換えコストっていう視点でどうかひとつ あ、でも実装系別の頭おかしくなるコンパイルオプションやらバウンダリやらのメモリモデル考えると、Goのほうが実質勝ってないか学習コスト？ http://mevius.5ch.net/test/read.cgi/tech/1605467680/987
988: デフォルトの名無しさん [sage] 2022/02/27(日) 00:11:21.81 ID:uWHjNeVw >>973 ちなみに速さやらサイズでは当然にCとかの圧勝だろ普通に 関数呼び出しごとにオーバーヘッドのかかるGoが単純な速度で勝てる道理はない http://mevius.5ch.net/test/read.cgi/tech/1605467680/988
989: デフォルトの名無しさん [sage] 2022/02/27(日) 00:23:35.14 ID:uWHjNeVw >>973 C#というか.Netのwpfは好き 一般的な手法じゃないだろうけど、MVVMのVM部分を単体テストできて(ディスパッチャ細工してメインスレッドで走らせる) http://mevius.5ch.net/test/read.cgi/tech/1605467680/989
990: デフォルトの名無しさん [sage] 2022/02/27(日) 00:44:59.79 ID:PVy06kKY >>985 > Goとは異なりスタックレスなので やたらこれを強調しているが、goでもgoroutineにローカルキュー（＝関数ポインタの配列）を用意して、順に食わせれば、 各タスク毎にスタックを用意する必要なんて無くて、普通にエミュレーション出来るよ。 (ただしGo信者的にはこれは負けだからやらないとも思うが） ただこの場合、各タスクが止まらない前提ならこれでいいが、 止めて切り替える分には一般的にはスタック領域が必要になる。 (自動変数を全部ヒープ上に確保すればスタック無しでもいいが、これは遅くなるので多分やってないと思う) ユーザーが確保しなくていいだけで、実際はランタイムかコンパイラが確保してくれてるだけじゃないか？ http://mevius.5ch.net/test/read.cgi/tech/1605467680/990
991: デフォルトの名無しさん [sage] 2022/02/27(日) 00:50:50.94 ID:PVy06kKY >>988 > 関数呼び出しごとにオーバーヘッドのかかるGo かからないような気がするが、自信はない。かかる理由って何？ http://mevius.5ch.net/test/read.cgi/tech/1605467680/991
992: デフォルトの名無しさん [sage] 2022/02/27(日) 02:41:36.05 ID:uWHjNeVw >>991 Goは関数呼び出しごとにスタックをチェックして、不足してたなら拡大するから 関数ごとの静的な自動変数サイズと比較してるだけだと思うけど、そういう処理のおかげで初期スタックサイズを抑えてる https://postd.cc/performance-without-the-event-loop/ http://mevius.5ch.net/test/read.cgi/tech/1605467680/992
993: デフォルトの名無しさん [sage] 2022/02/27(日) 02:47:33.19 ID:uWHjNeVw >>991 「十分な空間がない場合、ランタイムはヒープに対して大きなスタックセグメントを割り当て、現在のスタックの内容を新しいセグメントにコピーし、古いセグメントを解放し、それから関数呼び出しを再開します。」 http://mevius.5ch.net/test/read.cgi/tech/1605467680/993
994: デフォルトの名無しさん [sage] 2022/02/27(日) 03:00:02.25 ID:uWHjNeVw >>991 毎回拡張する訳じゃないけどそのためのチェックは毎回走るんで、単にサブルーチンを呼ぶだけの他言語よりは余分な仕事をしている おそらくチェックは必要な回数だけだとは思う(ループ内での呼び出しとかの最適化は考えてないとは思わないから) http://mevius.5ch.net/test/read.cgi/tech/1605467680/994
995: デフォルトの名無しさん [sage] 2022/02/27(日) 06:52:35.32 ID:+yReYAPt compiler explorer(https://godbolt.org/)で、goコンパイル結果を普通のamd64用のアセンブラ見ること出来ないの？(Plan9でなく) http://mevius.5ch.net/test/read.cgi/tech/1605467680/995
996: デフォルトの名無しさん [sage] 2022/02/27(日) 07:42:28.85 ID:uWHjNeVw 次スレ建ててくる http://mevius.5ch.net/test/read.cgi/tech/1605467680/996
997: デフォルトの名無しさん [sage] 2022/02/27(日) 07:44:00.44 ID:uWHjNeVw Go language part 5 https://mevius.5ch.net/test/read.cgi/tech/1645915400/ http://mevius.5ch.net/test/read.cgi/tech/1605467680/997
998: デフォルトの名無しさん [sage] 2022/02/27(日) 07:56:25.05 ID:nXG/aSfD >>990 Rustの非同期タスクは内部的には単純な状態マシンとなり何度も再入可能なコルーチンと同じ状況になります その中の変数はRustのクロージャがその環境の変数をキャプチャするのと同じだからもちろんメモリを確保します だからスタックレスで何度も呼べるクロージャみたいな状況でスタック自体はプロセス全体で1本のままとなります もちろんその非同期タスクから他の非同期でない普通の関数を呼べば通常と同じくスタックが伸びて使われていきます 一方でその非同期タスクから他の非同期な関数を呼ぶとその非同期タスクから一旦離脱してスケジューラーへ戻ります 最初に書いたように「単純な状態マシンとなり何度も再入可能なコルーチン」となっているので再び再開できます 以上がスタックレスなのにRustの非同期タスクがメモリの許す限り多く動くことができる仕組みです http://mevius.5ch.net/test/read.cgi/tech/1605467680/998
999: デフォルトの名無しさん [sage] 2022/02/27(日) 08:07:16.26 ID:c9v4owXb ワッチョイ無しかー(´・ω・｀) http://mevius.5ch.net/test/read.cgi/tech/1605467680/999
1000: デフォルトの名無しさん [sage] 2022/02/27(日) 08:16:41.16 ID:+yReYAPt 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もデカい http://mevius.5ch.net/test/read.cgi/tech/1605467680/1000
1001: 1001 [] ID:Thread このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 468日 4時間 2分 1秒 http://mevius.5ch.net/test/read.cgi/tech/1605467680/1001
1002: 1002 [] ID:Thread 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。 運営にご協力お願いいたします。 ─────────────────── 《プレミアム会員の主な特典》 ★ 5ちゃんねる専用ブラウザからの広告除去 ★ 5ちゃんねるの過去ログを取得 ★ 書き込み規制の緩和 ─────────────────── 会員登録には個人情報は一切必要ありません。 月300円から匿名でご購入いただけます。 ▼ プレミアム会員登録はこちら ▼ https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼ https://login.5ch.net/login.php http://mevius.5ch.net/test/read.cgi/tech/1605467680/1002
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.022s