[過去ﾛｸﾞ] Go language part 5 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
27(3): デフォルトの名無しさん [sage] 2022/02/28(月) 14:52:59.85 ID:xNWA4laA(1/2) AAS
このasyncおじさんは何も分かってないと思う・・・
nodeでasync/awaitが通るのは、シングルスレッドですべてのメモリーが一緒のためで、Goのようにgoroutineで実際に
割り当てられているCPUやスレッドが分からないようにあえてしている言語で、asyncなんて導入するわけない。
async/awaitがある言語でそれがThreadを混ぜ込める言語もあるが、それだってI/Oをブロックしている処理の終わりに
ただ同じスレッドを再割り当てするだけ。スレッド境界を越えてメモリーコピーあるいは同期なんてしてたら破綻する
async/awaitのもとになるような、多くのスクリプト言語でyield、つまりジェネレータの重要なユースケースは、I/Oブロックの
待ちで違う処理を行うことだが、それはI/Oバウンドな待ちでしか処理が切り替わらないことを意味する。
28(2): デフォルトの名無しさん [sage] 2022/02/28(月) 15:07:48.45 ID:xNWA4laA(2/2) AAS
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でも投下してこい。それすら出来ないなら
お前は不当に他言語を卑下してる卑怯者だぜ。どうせボコボコにされる
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.159s*