Go language part 3

[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞
抽出解除ﾚｽ栞

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

796: デフォルトの名無しさん [sage] 2020/11/01(日) 13:36:21.44 ID:0aiHjqpe

>>791
ちなみにgreenスレッドスイッチは何で起動してるか分かるか？

なおgreenthreadについてはありがとう。これだと色々辻褄が合う。
781のブログも、「そもそもgoroutineってそんなに使いたいか？」という疑問があったのだが、
greenthreadでchannel同期なら、実装は単なるFIFO＝リングバッファだから原理的に最速だ。
だから何でもかんでも「goroutineに出来る物はgoroutineにする」という方向性で悪ノリしたくなるのは分かる。
ただ、2KBはオーバースペック過ぎるから、それで頓死するのも分かる。

さてスレッドスイッチ、理想的にはキャッシュミスでgreenthreadスイッチが行われればいいのだが、
現状のx86ではこれは出来ないよな？
そもそも例外はOSに行ってしまうし、キャッシュミス時はそのCPUスレッドはそこでストールしてしまう。
一番近いのはTLBミス例外だが、それもOS行きだ。
ページフォールトしていたらプロセススイッチで終わり、
していなければそのまま処理が返ってきてキャッシュが充足されるまでストールしたまま待たされるはずだが、
そこでCPUが遊んでいる時間を他greenthreadで埋めてしまえ、というのは思想としては分かる。
ランタイム側で「TLBミスからの復帰」だと分かればgreenthreadスイッチ可能だが、
一般的には例外からの復帰はユーザープロセスからは見えないだろうから、おそらくカーネルに手を入れないと無理だ。
それでもやってしまえば面白い。ただ、この場合にgreenthread間でスラッシングした場合は悲惨なことになるが。

というわけで、スレッドスイッチ起動のネタは分かるか？
従来通りタイマなら、面白くもないがまあ、というところ。
greenthreadで最小構成ならスレッドスイッチのコストはPC/SP/Flags復帰分＝関数1回呼び出し分でしかないから、スイッチし放題ではある。
だから豆にスイッチしまくりというのも面白いが、それでもキャッシュミスでのストールは避けられない。
そこでハードウェアサポートがあってキャッシュミス時にgreethreadスイッチが出来れば圧倒的に面白くなるが、
現状のx86だと出来ないよな？

http://mevius.5ch.net/test/read.cgi/tech/1571315884/796

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

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.046s