[過去ﾛｸﾞ] プログラミング言語 Rust 4 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
575(3): 2018/01/07(日)16:38 ID:lYFenZIw(1) AAS
>>574
単純なCだけ頭一つ抜けてて、C++とRustはvtableやsmart pointer由来の遅さを抱えた同じグループ
578(1): 2018/01/07(日)20:07 ID:QaVgU45N(1) AAS
>>575
検証結果plz
最適化コンパイラがない時代ならともかく今時のコンパイラで有意な差が出るとは思えない
596(1): 2018/01/08(月)21:23 ID:aKL7Lo8F(1/2) AAS
>>575
速度優先なら
vtable作らない
smartpointer使わない
602(1): 2018/01/08(月)23:59 ID:y4IOANaR(3/3) AAS
>>575 >>596
Rustは実装にもよるけど vtable はほとんど使わないはずだよ。
「ジェネリックとトレイト境界」を使えば引数に関しては静的ディスパッチが可能。
戻り値のほうは「ジェネリックとトレイト境界」じゃどうにもできないけど、
こっちはTagged Union 使えば大体は何とかなる。
現状、クロージャを返す場合はトレイトオブジェクトを使わざるを得ないけど、
クロージャを返すことって稀だし、そこまで気にするようなことじゃないと思ってる。
Cにはそもそもクロージャ自体が存在しないわけだし。C++でもクロージャは一般的じゃない。
smart pointer に関しても unique_ptr なら遅くはならない。(ほとんど誤差みたいなもの)
だって unique_ptr は参照カウンタ使ってないし、Rallの仕組みを使って構造体(スタック)に
ポインタを持ってデストラクタで解放を行ってるだけだから、その程度で遅くなるわけがない。
そして、Rustはデフォルトが C++の unique_ptr と同じだからやはり遅くはならないはず。
遅くなるのは内部で参照カウンタを使ってるshared_ptrとweek_ptrの2つ。
Rustの場合は参照カウンタは Rc or Arc として標準ライブラリに用意されてる。
まあ、Rustで Rc or Arc を全く使わずに作るってのはちょっと現実的じゃないけど。
まぁ、自分もそれほど詳しいわけじゃないけど、
vtableとsmart pointer はRustが遅い理由にはならないんじゃないかな。
RustがC, C++ と比べて少し遅い理由は他にあると思うよ。
個人的にはまだコンパイラが成熟してないってのが主な理由だと思ってるけど。
結構いっぱい書いたけど、やっぱり結論としてはC, C++, Rust の速度差は普通に使う分には気にすようなものじゃないと思う。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.041s