[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
784(2): 2020/11/01(日)10:42 ID:0aiHjqpe(2/12) AAS
>>782
逆に言えばそれ以外の環境では他言語に劣るわけだろ。
元々は多分、命名からして、コルーチンをgoroutineで、ということなのだと思う。
コルーチンは通常は本体側と交代で間欠的に動作する前提で書かれているから、スレッドで切り離すことはしない。
ただ、もしそれが本体と並行に動作可能なら、スレッドとして切り離せば、
本体側が動いている間に次のyieldまで動作させられ、コルーチン部分の処理時間を見た目ゼロに出来る。
実際、大半のコルーチンはこれが可能なはずで、これまでは単に面倒/スレッド生成消滅のコストの為にそこまでやらなかっただけ。
だから、スレッドよりもっとお手軽で軽いgoroutineを用意すれば、という訳だ。
OSでの並行はprocessだが、multi processは重すぎるのでアプリ内processとしてthreadが出来た。
それと同様に、thread内の並行として、goroutineという、もう一段軽い物を用意した。
省7
790(1): 2020/11/01(日)11:13 ID:Gkt9gY6r(2/2) AAS
>>784
ここで言ってるメニーコア環境がXeon PhiなどではなくXeonやEPYCのようなパッケージのコア数の向上とそれを積んだ大規模分散環境の話だって伝わってないって事は分かった
どこまで適用できるかって話に関してはG社が自分とこに使えればそれでひとまずOKというラインがあるのでそっから先は知った事ではなくて良いのでは？
↑は >>785 にも続く話だけど現実的でないとか上手く行ってないとか結局それが現実的でなく上手くいかないタイプの分野・会社に君がいるだけじゃないの？と思ってしまうよ
792(1): 2020/11/01(日)11:45 ID:b3NlQgn4(1/3) AAS
>>784
コルーチンを指向していたならchannelなんて使わんだろう。
どっちかというと軽量プロセスの方向性。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.028s