C vs C++ vs Rust Part.3

1 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 22:19:47.56 ID:avZQ9Wm7.net] 闘え ※前スレ C++ vs Rust https://mevius.5ch.net/test/read.cgi/tech/1619219089/ C vs C++ vs Rust Part.2 https://mevius.5ch.net/test/read.cgi/tech/1639539350/ 2 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 22:28:23.63 ID:4DQKoSsj.net] 前スレまでのあらすじ --- 987 デフォルトの名無しさん sage 2022/01/27(木) 17:14:15.89 ID:hWkHkx2k >>986 > だから専有機なら上限で用いる 「現在の主流」というのは、「専有機」での話？ それとも一般的な話？ 994 デフォルトの名無しさん sage 2022/01/27(木) 17:52:30.63 ID:LojT3k5n 自分が理解できないと相手が敵かつ全て同一人物に見える病気のパターンかねｗ 皆普通に同じことを指している 何が理解できないのか素直に言ってごらん 995 デフォルトの名無しさん sage 2022/01/27(木) 17:55:13.00 ID:hWkHkx2k >>994 >>987の質問に答えてから続けてね 3 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 22:58:22.92 ID:37eem+FW.net] あらすじが全くわからんw 4 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 23:13:49.64 ID:cK3g3Gve.net] 彼はこの部分がわからなくて連投していたみたいだから横から補足説明しましょう > 大雑把にI/O観点で二つに分けると > 昔は同期I/Oでブロックされるからマルチスレッド > 今は非同期プログラミングでスレッド数はシングルからCPUコア数が上限 > RustのFutureタスク、GoのGoルーチン、JavaScriptの非同期Promiseやコールバック > いずれもプロセス内スケジューラがI/O多重化(select/epoll)やタイマーなど管理して非同期プログラミングを支えている 昔は自分でOSスレッドを立ち上げて使っていたのに対して 今は自分で立ち上げるのがOSスレッドではなくそれよりも粒度が細かく軽い非同期なタスクで OSスレッドを立ち上げる役割はそれらタスクの非同期なスケジューリングをするランタイムで そのスレッド立ち上げ個数は効率最大のためCPUコアスレッド総数と一致するのが望ましいため GoやRustなどではデフォルト値がそうなっていますよってことですよね もちろん個数を1個つまりシングルスレッドに設定しても動くところが決定的な違いですね OSがスケジューリングしてくれるけど重くて大きくリソースを喰うOSスレッドを今は直接使わずに > RustのFutureタスク、GoのGoルーチン、JavaScriptの非同期Promiseやコールバック これらのもっと軽くて小さなタスクを使うことで何万も同時に処理できるようになったという話ですね ちなみにRustでは昔と同じ状況にスレッドとタスクを1:1(=n:n)でも使えますし シングルスレッドにして1:nでも使えますし上述の状況は汎用的なm:nになりますね 5 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 23:14:48.99 ID:fMPJxSq8.net] 明らかに間違ってることを自信ありげに語るのはいつものこと その人達用の隔離スレだから >>1乙 6 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 23:25:15.10 ID:iujD8pk9.net] 横から？w 本人だろ、お前w 7 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 23:31:40.86 ID:m/Awlcjw.net] 複製おじさんのいつもの自演です 8 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 23:34:30.76 ID:iujD8pk9.net] 次はgoogleで2件しかヒットしない、「プロセス内スケジューラ」については説明してくれw 9 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 23:49:40.45 ID:cK3g3Gve.net] 非同期タスク群のスケジューリングをするランタイム部分のことではないでしょうか 一般的にプロセスの中に1つだと各スレッドへタスクを割り振るコストが高くて 各スレッドの中に独立して1つずつだと暇なスレッドと多忙なスレッドが偏るデメリットがあり GoでもRustでもそれらのスケジューリング問題を改善するために 各スレッド内に独立キューを持って効率的に処理しつつもグローバルキューも備えることで解決しているようですね 10 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 00:05:15.17 ID:EpTP27or.net] 複製おじはGoでもRustでもまともに非同期プログラミングやったことないんだな 11 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 00:14:38.44 ID:9bCXgVDe.net] >>8 OSスレッドがOSによりスケジューリングされることに対する対比じゃね？ タスクは各プロセスの中にスケジューラーがある Goは言語ランタイムの中だがRustは各自が好きなのを選んだり自作も可能 12 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 01:31:02.15 ID:DUuAybqk.net] どうせRustは普及しないんじゃないかな、知らんけど。 13 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 08:21:58.40 ID:OuJICsLX.net] rustはc++を食うことがあってもピュアcを食うことはなさそう 14 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 08:42:08.00 ID:3x0JFp6u.net] Cは誤解を恐れずに言えばアセンブリ言語みたいなもんだからな 15 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 13:14:51.22 ID:7T77Q24K.net] >>13 C++ 98以前は Cと似てるし、ライブラリも言語とは無関係に自由に作れたから大丈夫。C++11以後はダメ言語になった。 16 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 13:17:06.82 ID:7T77Q24K.net] そもそも、CやC++が普及したのはTurboCのおかげ。 TurboCはライブラリが分かり易かった。 C++11以後、言語もSTLも両方腐っていてTurboCとは全く違うようになり、 人気もがた落ちになった。 17 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 15:22:28.01 ID:ePoQjqFg.net] 何頓珍漢な事言ってんだこのバカ 18 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 18:58:54.57 ID:9bCXgVDe.net] >>8 OSによるプロセスやOSスレッドのスケジューラではなく プロセスの中で動くタスクのためのスケジューラ 各言語によって言語機能として備えている場合と外部ライブラリによる場合がある Rustではその中間の形態で言語機能としてはasync/awaitの枠組みのみ提供 さらに標準ライブラリとしてFutureやWakerなどの必要とする定義のみ提供 実際に動作するスケジューラは外部ライブラリで様々な提供がなされ自作もできる その他はこのスライドの前半の解説など参照 Rustのasync/awaitとスケジューラの話 https://speakerdeck.com/osuke/rust-async-await 19 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 21:04:45.07 ID:zI6nuxFY.net] 前スレ946の三つのサイトから数値を入手して和を求める例を練習のためにやってみたんだが httpのheader取得までとbody取得の2回awaitが入るのがなるほどと思った あと文字列を数値に変換parseも当然必要だったのでawait部分がちょっと長い #[async_std::main] async fn main() -> surf::Result<()> { let n1 = surf::get("https://httpbin.org/base64/MTEx"); // 111 let n2 = surf::get("https://httpbin.org/base64/MjIy"); // 222 let n3 = surf::get("https://httpbin.org/base64/MzMz"); // 333 let sum = n1.await?.body_string().await?.parse::<i32>()? + n2.await?.body_string().await?.parse::<i32>()? + n3.await?.body_string().await?.parse::<i32>()?; assert_eq!(666, sum); Ok(()) } 利用させてもらったテストサイトはURLで返す値など指定できるhttpbin.org これで動いて値取得もできて合計値assertも通ったのだが実は落とし穴があることに気付いた 20 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 21:49:38.11 ID:YDzvJ7+G.net] 元のJSのコードもだけど await連発すんなよw 21 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 22:11:12.59 ID:zI6nuxFY.net] そのテストサイトにhttp返答を遅延させるdelay機能があるので試した時に露見した 同時に指定値を返せないようなので数値化と足し算の意味はないが遅延時間を知りたかった let d1 = surf::get("https://httpbin.org/delay/4"); // 4秒 let d2 = surf::get("https://httpbin.org/delay/5"); // 5秒 let d3 = surf::get("https://httpbin.org/delay/3"); // 3秒 let sum = d1.await?.body_string().await?.parse::<i32>().unwrap_or(0) + d2.await?.body_string().await?.parse::<i32>().unwrap_or(0) + d3.await?.body_string().await?.parse::<i32>().unwrap_or(0); 結果は12秒かかってしまい期待と異なり直列に実行されていた 肝心なことを忘れていた 22 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 23:09:26.07 ID:zI6nuxFY.net] JavaScriptではPromiseを返す関数を3つ呼べばそれで3つ並行に実行される しかしRustでは並行に動くタスクを自分で明示的に起動しなければいけなかったのだ よく考えればGoでも自分で明示的にgoと前置指定することで別goルーチンを起動している Rustではそれがspawnでありgoと同じくそれによりスケジューラに登録されるようだ use async_std::task::spawn; let d1 = spawn(surf::get("https://httpbin.org/delay/4")); // 4秒 let d2 = spawn(surf::get("https://httpbin.org/delay/5")); // 5秒 let d3 = spawn(surf::get("https://httpbin.org/delay/3")); // 3秒 このようにspawnを付けて以降は同じ実行をすると全体で結果5秒となり並行に実行された 言語自体に魔法の仕組みはなく自分で明示的にスケジューラに登録指定するのはわかりやすくて安心した そのスケジューラも手作りできるらしく興味深い 23 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 23:23:01.28 ID:JUEBwV02.net] 自分でblock_on書かないとRustのasyncは身に付かない 24 名前：デフォルトの名無しさん mailto:sage [2022/01/28(金) 23:49:49.26 ID:zI6nuxFY.net] >>23 use async_std::task::{block_on, spawn};の時 このblock_onを使った fn main() -> surf::Result<()> { block_on(async { let d1 = spawn(surf::get("https://httpbin.org/delay/4")); // 略 }) } の簡略版が>>19で書いた #[async_std::main] async fn main() -> surf::Result<()> { let d1 = spawn(surf::get("https://httpbin.org/delay/4")); // 略 } ってことか つまりasync { ... } という非同期ブロックをblock_onによりスケジューラに実行させているわけだ 当たり前だがspawnする以前に最初からスケジューラの掌の上で踊っていたのであった じゃないと全体を並行に実行できないもんな 25 名前：デフォルトの名無しさん mailto:sage [2022/01/29(土) 13:58:43.26 ID:AW7V4mOd.net] Rustのasync/awaitはコンパイルされると単純なステートマシンになる 例えばasyncブロック内にfuture1.awaitとfuture2.awaitが順に呼び出されるとする 最初はfuture1をpollする状態でpending中はpendingを返す そこでreadyになればfuture2をpollする状態へ遷移 そこでもreadyになれば全体としてreadyを返す状態へ遷移 結局スタックレスなコルーチンを実現しているだけなので非常に軽い 26 名前：デフォルトの名無しさん [2022/01/29(土) 22:23:27.99 ID:12259hRt.net] 起動も切替もスレッドより軽くてリソースも喰わないなら 非同期タスクの欠点は何だ？ 27 名前：デフォルトの名無しさん mailto:sage [2022/01/29(土) 23:26:45.54 ID:7irU+4ae.net] Rustの場合軽量タスクはプリエンプティブじゃないので、変なコーディングすると特定のタスクが実行され続けて、他のタスクがいつまでも実行されないことがある あとは、OSのスレッドじゃないからスレッドの属性や権限をタスク単位で異なる物にすることはできないとか 28 名前：デフォルトの名無しさん mailto:sage [2022/01/29(土) 23:44:38.93 ID:AW7V4mOd.net] >>27 前者は間違えて同期ブロッキングする関数を呼んでブロックしてしまった場合 および長時間ずっと全く非同期関数を呼ばずに計算し続けるか暴走する場合 これらはバグならfixで解決 バグでないなら非同期タスク実行スレッドとは別に専用スレッドを用意して実行できるスケジューラもあるのでそれを利用 29 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 00:54:30.09 ID:zeCbxF6p.net] >>28 同じ処理でも入力内容次第で変わるからそんな簡単にいかないよ 30 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 01:16:02.14 ID:iWlFH2We.net] async-stdならgoみたいにタスクが一定時間経っても制御返してくれないときに勝手にスレッド起こしてくれるんじゃなかったっけ 31 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 18:58:15.77 ID:9ei8l7Ku.net] >>29 入出力が行なわれたらタスクのスイッチングが発生するので 意図的にブロッキングするものを呼んでブロックしているケースを除くと いつまでもタスクが切り替わらないのは演算のみを延々と続けるケースのみになる 対応策としては自分で定期的に手放すか以下の方法で回避 >>30 それは様々な問題点で中止 結局tokioもasync_stdもそのような特殊ケースはspawn()の代わりにspawn_blocking()することで タスクのスイッチングに影響が出ないように別スレッドで実行させる方針 その場合は結局スレッドを自分で起動して同期ブロッキングで使う昔からの方法と実質同じだが そのような特殊なケースも含めて統一的にタスクを扱える 32 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 20:50:10.05 ID:dly2JmLT.net] >>31 延々と演算を続ける意図はなかったのに結果としてそうなる場合があるということ それを最初から想定できてyieldを挟めるなら問題ないのだが現実はそうはなっていない https://tokio.rs/blog/2020-04-preemption 33 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 21:57:34.87 ID:C4ZQL08k.net] そのbudget方式は戻ってこないとペナルティ与えられないから本質的な解決になっていない yield相当をコンパイラが上手く挟むのも無理だからプログラマーが自らすればいい 34 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 22:13:02.89 ID:46YJeJfB.net] 歴史から学ばない人 35 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 00:52:40.26 ID:wgfsi16C.net] 歴史ってのがマルチタスクOSにおける cooperative vs preemptive の話だとするなら前提が違いすぎない？ 任意のアプリケーションが動く可能性のあるOSと自身のプログラムのルーチンが実行されるアプリとではスケジューラに求められる制約条件は違って然るべきかと 36 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 07:30:22.38 ID:qlFEomu1.net] シングルスレッドかつcooperativeなJavaScriptがNode.jsを含めて成功しているように問題なく動作する 同期ブロッキングを完全排除してしまえばタスク切り替えが起きない場合すなわちスケジューラに戻らない場合は 入出力もなくループでメモリ上演算を繰り返している場合となる そのような場合でもループ内で自分で定期的にスケジューラへ制御を戻してやればよい そのためにRustではtask::yield_now()がある 37 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 10:15:42.24 ID:O/M0tTc6.net] イベントループがハングアップした時の対処とか考えたことないでしょ？ バグだからfixすればいいじゃ能がない 歴史に学ぶといいよ 38 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 10:24:59.23 ID:qlFEomu1.net] >>37 GoやJavaScriptなどは言語内蔵だが問題が起きたことはない Rustは言語から切り離されているが同様 いずれもそれらのランタイムの製作者以外がその部分のコードを触ることはなくバグが発生しようがない 39 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 10:27:00.53 ID:/Hwves02.net] >>37 > イベントループがハングアップした時の対処とか考えたことないでしょ？ そういうのは上位で対処（タイムアウトでプロセス再起動とか）することもあるからケースバイケースでしかない 40 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 10:46:15.49 ID:5QuAHu0k.net] イベントループがハングアップするってなに？ epoll_waitをブロッキングで使う場合でもタイムアウト設定すればハングアップなんてしないでしょ？ 41 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 11:35:28.84 ID:BNlzdeLS.net] タイムアウト設定忘れみたいなバグの話でしょ そんなに引っ張る話でもないと思う 42 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 12:52:34.54 ID:qlFEomu1.net] >>41 それは万が一あるとしても非同期スケジューラランタイム実装者の管轄 その利用者である一般プログラマーが引き起こすバグではないため関係ない 43 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:02:21.71 ID:dnOSCP4X.net] > epoll_waitをブロッキングで使う場合でもタイムアウト設定すればハングアップなんてしないでしょ？ の話だぞ？ 44 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:17:00.70 ID:wgfsi16C.net] 歴史って言葉持ち出してるんだしそんなしょうもない話じゃなくてもっと有名なエピソードなんじゃないの 45 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:24:49.76 ID:HGCqFbKg.net] 「Rustのタスクの欠点は？」 「プリエンプティブじゃないところ」 「プログラマーが注意すればいいだけだから問題ない」 46 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:35:30.64 ID:qlFEomu1.net] そりゃepollやselect相当を自分で使っていてミスをすればイベントループがハングアップするのは当たり前 しかし非同期タスクのイベントループは非同期スケジューラの中にあって自分でepollやselectを扱わなくてよくなった だから自分のミスでイベントループがハングアップすることはなくなった それ以前の歴史では色々あったが状況が変わった 47 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:51:12.77 ID:dnOSCP4X.net] はいはい、理想的な環境で羨ましいですね これでいいかな？w 48 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 14:52:14.32 ID:QZLkrRiL.net] メモリ開放忘れみたいなバグの話でしょ そんなに引っ張る話でもないと思う 49 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 14:57:56.44 ID:wgfsi16C.net] バグ耐性高めるためにタスクをプリエンプティブにしたいならすれば良いのでは プログラマーのスタンスに合わせて適切な物を選べるよう選択肢は用意されてると思うが 何について言い争ってるのかよくわからない 50 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 15:37:58.82 ID:UHXhumHV.net] GoやNode.jsが上手くいってる主因は非同期並行プログラミングのしやすさ 両者は方向性が真逆だけどそこが共通点で時代の要請 逆にC++が振るわないのは非同期並行プログラミングのしにくさ その状況でRustが登場して非同期並行プログラミングのしやすい環境も装備されたという流れ 51 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 18:03:53.30 ID:dLpRlGxR.net] >>49 タスクはプリエンプティブにはできないよ スレッド使えって言ってるの？ 52 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 18:33:21.76 ID:fs07R1AL.net] >>51 そうじゃね？ 53 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 18:56:25.41 ID:UHXhumHV.net] Node.jsもプリエンプティブではないけど困っていない タスクがプリエンプティブではないことを欠点だと主張する人は 欠点だという具体的な例を挙げてから主張すべき 54 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 19:02:29.41 ID:wgfsi16C.net] >>51 そうだよ ここで言うタスクはtokioやasync-stdの用語のタスクのことね spawn_blockingでタスク生成すれば専用スレッドが割り当てられるので特定のタスク選んでプリエンプティブにできる (OSにタスクスイッチの制御を委譲できる) 55 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 19:03:44.27 ID:wgfsi16C.net] >>53 spawn_blockingみたいなAPIが用意されてるのはプリエンプティブなタスクの需要はあるんじゃないの そこを否定する意味が分からない 56 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 19:28:57.02 ID:UHXhumHV.net] >>54 それはレイヤーが違う まずOSスレッドは何をしようが常にプリエンプティブ だからOSスレッド上で動いているタスクも途中で一時中断されたり再開されたりしうる だからといってタスクをプリエンプティブだと言わないのはタスクの階層で話をしているため タスクスケジューラに制御を戻さない限り他のタスクに切り替わらないため「プリエンプティブではない」と言われる 次にspawn_blockingで起動されるのもタスクの一つ だからタスクスケジューラが管理するスレッドの中で動く それがspawnだと一つのスレッドに対するキューに複数のタスクが割り当てられる 一方でspawn_blockingは一つのスレッドに対するキューにそのタスクのみが割り当てられる それだけの違いであり両者ともにタスクスケジューラの管理下にあるタスクである もちろん動作中も終了後もタスクとして同じ扱い つまりspawn_blockingはプリエンプティブにするものではない 同じタスクでありスタックレスなコルーチンであることも同じ >>55 その意見は成立していない 57 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 19:56:01.95 ID:wgfsi16C.net] >>56 確かにプリエンプティブという用語を使ったのは適切ではなかったかもね タスクがスレッドを占有するか他タスクと共有するか選択できると言い換えればよいかな 58 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 21:28:17.75 ID:L8OnQfxN.net] >>54 最初からspawn_blockingで呼ぶべきだと誰もがわかるような処理だけじゃないよ Goと同じでRustもそのうちプリエンプティブなスケジューラが作れるような機構を用意すると思うけどね 59 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 22:11:33.46 ID:qlFEomu1.net] >>58 preemptiveは必要ない シングルスレッドかつcooperativeなJavaScriptがNode.jsを含めて問題なく動作し成功している 60 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 22:59:08.63 ID:UPbAych9.net] Rustってデータ競合を許さない、ってあたりが並列処理とめちゃくちゃ相性良いように見えるけど、 まだそういうスケジューラとか非同期ランタイムらへんの仕組みがちっとも枯れてないんだね 将来のデファクトがどうなりそうか、ってのはある程度見えてきてるのかな？ 61 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:10:00.73 ID:9ggC0jgK.net] >>59 tokioの開発者もasync-stdの開発者もそうは考えてない a major source of bugs and performance issues in concurrent programs: accidental blocking. https://async.rs/blog/stop-worrying-about-blocking-the-new-async-std-runtime/ 62 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:16:15.33 ID:UHXhumHV.net] >>61 それはすぐに廃止された そして現在tokioもasync-stdもプリエンプティブを許すコードは存在しない 63 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:18:46.34 ID:9ggC0jgK.net] >>62 知ってるよ 問題認識の話をしてるんじゃん 64 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:21:44.46 ID:9ggC0jgK.net] Node.jsはタスク単位で高い信頼性が求められるシステムでは使われない イベントループがブロックしたら他のタスクを道連れにしてプロセス丸ごと再起動する以外に対処法がないから それもexecution managerできちんとモニタリングしてればの話 JSやNodeとRustとはポジショニングが違う 65 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:28:55.88 ID:qlFEomu1.net] >>64 イベントループがブロックすることはない 何を言いたいのか意味不明 66 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:47:16.39 ID:UHXhumHV.net] >>64 Node.jsまで否定し始めるとは発狂もほどほどに 67 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 01:18:54.05 ID:NlOJHFhB.net] >>58 rustでプリエンプティブなタスクって実装できるのかね goみたいなシグナルでスイッチする仕組みは使えない気がするが 68 名前：デフォルトの名無しさん [2022/02/01(火) 09:02:19.73 ID:YxH4csZd.net] 昔は標準で出来たのに「そういうのはライブラリでやればいい」って嘯きながら削除して、そのあと一生それが出来る標準ライブラリが登場しないいつものRust 69 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 14:23:13.43 ID:fJKShZ3h.net] >>67 Cで実装できることはRustでも実装できる もちろんRustにもプリエンプティブなスケジューラは存在する Rustで書かれたプリエンプティブなリアルタイムOSもある >>68 Rust標準にプリエンプティブなタスクであるグリーンスレッドがあったのは Rust 1.0が正式リリース(2015年)となる以前Rust 〜0.9 の試行している時代 しかし重厚となりベアメタルもターゲットとするRustでは不適なため放棄 例えばGoの方法だと巨大なランタイムや個別スタックが必要など そのためRust標準ではスタックレスで軽いタスクを提供 さらに加えてasync/awaitもサポートし現在の軽く便利な環境となった 70 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 15:14:51.45 ID:7ZSm+F9e.net] あと5年寝かせれば使えるようになるかな 71 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 15:26:14.30 ID:0bEAn4zq.net] 別に今でもasync-stdを使えばええんちゃうか？ 72 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 15:54:32.70 ID:aP+3H5wQ.net] >>69 ユーザーランドでプリエンプティブなタスク実現するという話なんだけど 具体的にどのライブラリがサポートしてるの？ 73 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 16:14:56.52 ID:fJKShZ3h.net] >>71 async_stdでのプリエンプティブな試みは軽さの方針等に合わず、組み込まれないままで終わった >>72 上記の後継がasync_stdから独立していてsmolscaleとなっている 74 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 17:44:48.05 ID:IGt6++7z.net] >>72 lunaticってのがWASM限定だけどプリエンプティブ実現してるらしいよ WASM以外はコンパイラのサポートがないと無理 >>73 async-stdがやろうとしてたのはプリエンプティブではないよ 75 名前：デフォルトの名無しさん [2022/02/01(火) 23:44:18.44 ID:rLXhSAw+.net] 話題になってる分野だとC++が惨敗すぎて Rustの話題一色になってしまってる感じ 76 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 00:32:45.41 ID:Bknypv+c.net] C++が落ち目なのはまっとうなエンジニアの間では共通認識だろ 77 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 02:30:31.45 ID:YscELMZC.net] 78 名前：変な拡張し杉てワケワカになってきてるよな [] [ここ壊れてます] 79 名前：デフォルトの名無しさん [2022/02/02(水) 11:27:34.63 ID:jvlsF+ng.net] 変な拡張を使わなければ良いだけでは？　使いこなせないのを使えなとは言わない。 80 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 14:23:10.98 ID:X76n4047.net] RustがGo位の位置にたどり着くのは、あと何年かかるかね 81 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 15:00:57.22 ID:O+j3A95O.net] GoはWebとかのアプリケーションでカジュアルに使われるようになってきたから、使う人数もかなり多くなってきたけど、 Rustはそういうポジションにつくことないだろうから、現在のGoほどの人気になることはないんじゃない？ RustはC/C++のシェアを塗り替えていく程度だろうけど、そういう低レイヤーでは最強言語になりそう 82 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 15:03:25.91 ID:6tF6MeYL.net] RustがTIOBE Indexに出てくるのはいつなんだろう？w https://i.imgur.com/DNijd0h.jpg 83 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 22:30:37.00 ID:yDHN0aKU.net] 言語機能としてはC++が完敗だから 過去遺産しか誇るものがない 84 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 22:35:52.80 ID:/PkFuWcg.net] 何言ってんだこのバカ 85 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 22:46:31.08 ID:J71gX0gE.net] シェアもユーザー数も過去遺産と言われてしまえばそうだが そんなことは興味がないのでC++での非同期並行プログラミングについても語って欲しい 86 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 16:11:01.01 ID:VWdjVpzZ.net] C++の非同期っていうとstd::asyncとか？ 87 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 17:48:17.26 ID:rBa0lj+C.net] >>81 今26位で、Kotlin, Lua, Scalaとかより上なんだが 88 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 17:52:10.90 ID:6/rx3Wgr.net] >>86 COBOLより下なんかwwwww 89 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 18:30:47.00 ID:VWdjVpzZ.net] KotlinやScalaは結局流行らずJavaで十分だし Luaも一時期熱狂したけど記法や環境が多くの人の好みに合わずPerlのように嫌われてる RustもC/C++で十分という認識が強くて普及せずに一部の通好みに終わる可能性がある Rustは有力企業もプッシュしてるけど三つの言語の流行らない特徴を全て備えてる そうこうしてるうちにRustより優れた言語がぽっとでて席巻する未来だってある 90 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 18:38:00.04 ID:I6DodtQJ.net] 流行るの閾値高くない？ 何位以上になったら満足なんだ 91 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 18:48:22.27 ID:Y+zgwr9T.net] 普通にTop10じゃね？ 92 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 18:51:38.73 ID:OQgvAcI9.net] しかしTop10のVisualBasicやアセンブリが流行ってるとか言われてもあまり納得感はないな… 93 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 19:08:22.03 ID:Ajxf7YAY.net] TIOBEってトレンドを計測してるわけじゃなくて、あくまで検索エンジンで検索結果のヒット数が多かったランキングだからな CとかVBみたいに昔から一定の人気を保ち続けてるような言語がランキング高くなりやすいんじゃないかな 94 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 19:24:04.62 ID:I6DodtQJ.net] GitHub上の活動に基づいたランキングの方がプログラマ間の流行を知るには良いのかな https://madnight.github.io/githut/#/pull_requests/2021/4 95 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 19:40:42.80 ID:NxnOaIbO.net] せやな TIOBEはJavaScriptとアセンブラが隣の順位に並んでるとかおかしすぎるやろ 96 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 21:31:55.43 ID:8HqROgrm.net] >>88 Scalaも当時は熱狂的なファンがいたよなｗ 97 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 21:44:00.20 ID:OJ3iv254.net] ScalaはJVMベースだという点以外は特に悪いところは無いと思うんだが 98 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 23:27:45.66 ID:VxNIdQ9k.net] コラッツ関数を上手く実装できないかな 99 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:31:37.55 ID:tMDf8XuC.net] >>93 githubはアマチュアプログラマも沢山混じってる。 日経の調査ではプロのプログラマで最も使われている言語はC/C++だとされている。 なお、githubでも、CとC++を合算すると、9.82%、Rustは 0.694%で、 14.1倍の差がある。 100 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:34:29.27 ID:uF1Qc9S6.net] >>98 C vs C++でもあるんだから足したらだめでしょ 101 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:35:47.48 ID:tMDf8XuC.net] >>91 VisualBasicは結構使われているのではなかろうか。Excelなどで。 アセンブリは、基礎的なライブラリを作る人や組み込み、OS、BIOS を作ったり、グラフィックや数値計算の高速化を行う場合に必要な場合がある。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef