Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/07/31(水) 00:47:02.26

**デフォルトの名無しさん** · 2024/07/31(水) 00:47:20.93

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/

**デフォルトの名無しさん** · 2024/08/01(木) 16:24:10.41

>>1
乙

**デフォルトの名無しさん** · 2024/08/01(木) 18:56:40.59

https://prcdn.freetls.fastly.net/release_image/22017/53/22017-53-0b7b835a46293a3a03b057104ef0d96b-2440x1394.png

**デフォルトの名無しさん** · 2024/08/01(木) 23:55:38.74

「The Rust Foundation」は、人命や財産に関わるような安全性が決定的に重要になるシステムのために、
Rust言語を責任を持ってサポートするためのコンソーシアム「Safety-Critical Rust Consortium」の設立を発表しました。
設立には日本からWoven by Toyotaが参加

**デフォルトの名無しさん** · 2024/08/03(土) 23:20:11.39

今日調べたけど、RustでVecを拡張するときのサイズは前の2倍
JavaとRubyは1.5倍
Pythonはややこしくて約112.5%
Goはまず2倍だけど要素数が256を超えたら1.25倍におさえる

Rustはメモリ大目に使いがちかも

**デフォルトの名無しさん** · 2024/08/03(土) 23:47:40.31

Note that the exponential growth is important.
On each reallocation, we have to copy twice as much, but then it takes twice as long to fill up again.
These factors cancel out and we get (on average) constant-time .push().

**デフォルトの名無しさん** · 2024/08/04(日) 09:23:44.30

>>7
そのレートを利用者側で調整出来れば最強だった

**デフォルトの名無しさん** · 2024/08/04(日) 12:21:30.93

要らない
設定できてしまうと、測定もせずに小さなレートを設定してかえって遅くなるか、
神経質な人やチームなら必要もないのにいちいち測定する羽目になって生産性爆下がりするかの二択になる
本当に調整する価値のある状況ならちゃんと測定して決めるはずだし、その手間に比べたら自前で適宜リサイズするくらい全く問題にならない手間だろう

**デフォルトの名無しさん** · 2024/08/04(日) 12:26:21.94

>>7
それらGC言語は言語によってはメモリ管理上で仕方ない場合もあるのかもしれないが
C++やRustでは全く問題がないように作られているためパフォーマンスの良い2倍にしている
重要な点はキャパシティを2倍にしても実メモリ割り当ては2倍の消費をせずにその後ベクタを使用した長さ分だけに限られること

**デフォルトの名無しさん** · 2024/08/04(日) 12:30:08.75

んなわけあるかい
いつのまにか勝手に他に割り当てられたらキャパシティの意味ないでしょ

**デフォルトの名無しさん** · 2024/08/04(日) 12:37:16.12

>>12
実メモリ割り当てと仮想メモリ割り当ての違いを学ぼう
C++でもRustでもベクタのキャパ内の未使用エリアにアクセスしない
そのため未使用分の実メモリ割り当ては発生せずメモリ使用量の問題が起きない

**デフォルトの名無しさん** · 2024/08/04(日) 13:05:57.09

まーた複オジの嘘がはじまったね

**デフォルトの名無しさん** · 2024/08/04(日) 14:52:31.44

ユーザ空間の話してるときにカーネルの話混ぜないでよ

**デフォルトの名無しさん** · 2024/08/04(日) 15:19:59.12

仮想メモリと実メモリの話はそもそもGoやJavaやRubyでも同じだろ
「他の言語では必ず実メモリから取られるから物理メモリ以上の量のデータを確保できない、だからこれらの言語では動的配列の確保を2倍よりも小さい値ずつにしている」とでも言いたいのか？

**デフォルトの名無しさん** · 2024/08/04(日) 16:16:53.81

2倍にしていけば累積コピー回数を平均1回台に抑えられるメリットがあって
これは1+2+4+8+...+2^(n-2)+2^(n-1)=2^n-1で累積と同じになるからで
そのためC++(gccやclang)やRustは2倍を採用している状況

別問題として
2倍にしていくのはメモリがもったいなくね？があるけど
OSの仮想メモリ管理により実際に使われるまでは実メモリが使われることはないのでだいじょうぶ

さらに自らv.reserve(size)とサイズを指定する手段も用意されていて
size以下の間はお引っ越しコピーを避けることができるので見積もれる時は推奨だよ

**デフォルトの名無しさん** · 2024/08/04(日) 17:23:30.18

reallocationなんてパフォーマンス落ちるだけだし
with_capacityで自分でコントロールした方が良いと思う

**デフォルトの名無しさん** · 2024/08/04(日) 17:51:55.81

>>17
仮想メモリは消費しないのか？
32bit OSだと何もしなければ仮想メモリ4GBくらいしか無い気がするが。

**デフォルトの名無しさん** · 2024/08/04(日) 18:11:52.52

大きなサイズに育っていくならコピー回数が少なくなる毎回2倍が有利
仮想メモリが足りるか足りないかの限界状況で用いるならwith_capacity()やreserve()を最初から用いる

**デフォルトの名無しさん** · 2024/08/04(日) 18:28:12.58

フラグメンテーションの問題とかもあるから教科書通りの2倍固定よりも
Goのようにサイズが大きくなるにつれGrowth Factorも小さくしていくモデルのほうが一般的には良さそうだね

**デフォルトの名無しさん** · 2024/08/04(日) 18:43:06.42

gccでもclangでもC++のvectorは2倍にしていくから
これはRustの話ではなくて
2倍にしていくのが好ましいという長年の確立された知見が存在しているんだよ

**デフォルトの名無しさん** · 2024/08/04(日) 18:44:03.04

一方でガベージコレクション依存言語は内部のメモリ管理方式が全く異なるから
各言語個別の事情があるかもしれないけどこのスレの話題ではないね

**デフォルトの名無しさん** · 2024/08/04(日) 19:01:06.46

>>16
それらの言語は仮想メモリを持たない環境のことも考慮しての増加率なんだろうな

**デフォルトの名無しさん** · 2024/08/04(日) 19:12:09.84

仮想メモリを持たない環境でGC言語www

**デフォルトの名無しさん** · 2024/08/04(日) 19:40:14.37

思い込みの激しい人だこと

**デフォルトの名無しさん** · 2024/08/04(日) 19:41:13.70

Vecのアロケート戦略なんて標準ライブラリの実装レベルの話でしかないし、言語の特徴や優劣のような話でもないだろ
GoやJavaが2倍でも、逆にRustがより小さい値だったとしても、GCの有無とかの話に比べればずっと些細な話でしかないし
マジでなにいってるんだこいつとしか思えない

**デフォルトの名無しさん** · 2024/08/04(日) 19:48:10.28

>>25
Javaなんかはもともと組み込みをターゲットに開発された言語だね。
GCの有無と仮想メモリには何の関係もない。

**デフォルトの名無しさん** · 2024/08/04(日) 20:16:30.17

この議論
元々メモリ無駄食いのGC依存言語は無視してよくて、
Rustと同じジャンルのC++で長年議論されてきて2倍という結論が出ている。
どうしても2倍を批判したいならまずはgccやclangのC++に対して行なうとよいかと。

**デフォルトの名無しさん** · 2024/08/04(日) 20:31:51.43

2倍に対して突っ込んでるんじゃなくて延々と的外れなことを書いてることに対して突っ込まれてるだけでは？
平均的なコピー回数が少ない点で2倍は妥当ではあるけど、それも「よく使われる方法」くらいの意味しかない
C++でもMSVCだと1.5倍だったと思うし (今のバージョンでもそうかは未確認)

警備員[Lv.18] · 2024/08/04(日) 21:44:51.68

先生！チャンクアロケーター沼への入水希望者がこんなに

**デフォルトの名無しさん** · 2024/08/04(日) 22:06:56.31

>>21
Goがなぜそんなやり方をしているのか
実行しながら実メモリ使用量の変化を傍らでウォッチして見た
Goの大きなsliceでcapacityが増える時に実メモリ使用量が急激に増える
C++やRustではcapacityが増えてもそんな変動は起きない
つまりGoはこの問題のため2倍ではなく1.25倍にせざるをえないと思われる

**デフォルトの名無しさん** · 2024/08/05(月) 00:28:29.24

>>16の主張が間違っていた可能性があるな
例えば世代別GC各管理領域も拡張再編などが起きるため
C++/Rustとは状況が異なり
増やしたメモリ領域への書き込みがすぐに生じて実メモリ使用量が一気に増えてしまうのかもしれない

**デフォルトの名無しさん** · 2024/08/05(月) 02:39:57.82

C++で folly::fbvector を開発したFacebookによれば
成長係数2は最悪であることが数学的に証明されてるらしい
結論は1.5

https://github.com/facebook/folly/blob/main/folly/docs/FBVector.md

https://medium.com/smucs/fbvector-a-possible-replacement-for-std-vector-e46bb31b8a56

**デフォルトの名無しさん** · 2024/08/05(月) 05:37:35.60

>>34
読んでみたが色々とおかしい
まず1.5倍がベストな理由が書かれていない
次に2倍が悪い理由の説明と現実が合っていない

書かれている2倍が悪い理由を具体的な数字で書いてみると
例えばベクタの使用メモリサイズが育っていって1GBになっている時に
過去に使った半分の512MBの空きが抜け殻としてあり
さらにその前の分として半分の256MBの空きもありそれが過去に繰り返されていて
512MB + 256MB + 128MB + 64MB + ...
= 1GB未満のの再利用できていないメモリがあることになる
つまり再利用ができていないために合わせて約2GBのメモリを確保しているにも関わらず使っているのは半分の1GBなってしまう

という2倍が悪い理由が書かれている
しかしこれは現実と異なる
実際にベクタをゼロから地道にプッシュしていきそのサイズが1GBになった時
確保しているメモリサイズを調べると1GBである
再利用できていない昔の抜け殻が計1GB弱残るという話が現実と合っていない

**デフォルトの名無しさん** · 2024/08/05(月) 07:22:04.78

mmap/munmapでOSにメモリを返却できるから古い抜け殻は残らない
さらにmremapで実コピーをせずに利用可能サイズを増やすことができる
それらを呼び出すコストがかかるためその頻度が1.x倍より少なくなる2倍が好ましい

**デフォルトの名無しさん** · 2024/08/05(月) 12:04:08.00

話が難しいから何を言っているかじゃなくて誰が言ってるかでしか判断出来ねえ
そして5chをソースにfollyのreadmeを否定する意見を信じることも出来ねえ

**デフォルトの名無しさん** · 2024/08/05(月) 12:25:55.60

話は聞かせてもらった
最適な比率は2でも1.5でもなく黄金比1.618だな
こういう問題は大体フィボナッチ数列が正解になる
僕は数学に詳しいんだ

**デフォルトの名無しさん** · 2024/08/05(月) 12:37:42.98

>>37
わかる
もうちょいライトなユーザ向けのスレも欲しいかも

**デフォルトの名無しさん** · 2024/08/05(月) 12:46:25.51

>>37
むしろ彼しか問題にしてないだろ
g++とclang++のvectorとrustcのVecは2倍にしていく
もし2倍が致命的なら大論争になり変更されるはずだ
現実には実用面も含めて問題となっていない

**デフォルトの名無しさん** · 2024/08/05(月) 13:06:57.87

「致命的」に後退しちゃったねｗ

**デフォルトの名無しさん** · 2024/08/05(月) 13:12:56.68

Linux などのメモリ管理戦略ではアロケータは空いてる番地を返すだけで
アクセスするまで実メモリの割り当てをしない。 (割り当てを遅延させる。)

vector を極端に伸ばしたり縮めたりするなら話は別だが、
徐々に伸びていって最後に捨てる一般的なユースケースなら
倍率はテキトーでも理論的な効率はそんなに差はない。

**デフォルトの名無しさん** · 2024/08/05(月) 13:21:17.66

rustやc++では再割り当てが行われると参照が無効になるから2倍にして頻度を下げるのかも

**デフォルトの名無しさん** · 2024/08/05(月) 14:50:20.61

https://github.com/rust-lang/rust/issues/29931
これだね
2015年から議論されてるけど、結局1.5倍がいいという結論には至ってないし
実際1.5倍を試してみた結果パフォーマンスが落ちてるから単純に1.5倍にするのはダメそう
もし1.X倍でパフォーマンス上がる方法があるならそのissueに報告すれば採用されるかもよ

**デフォルトの名無しさん** · 2024/08/05(月) 15:01:05.36

>>44
rustcがベンチマークのネタに適してないんじゃないの？