Rust part15

**デフォルトの名無しさん** · 2022/05/12(木) 18:28:20.99

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

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

日本語の情報
https://rust-jp.rs/

※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/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

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

**デフォルトの名無しさん** · 2022/06/05(日) 18:25:46.65

まーたふぃぼなっち言ってるｗ
バカのひとつ覚えすなあｗ

**デフォルトの名無しさん** · 2022/06/05(日) 18:50:30.04

>>470
その>>295は他人叩きではないだろう
そのアルゴリズムではBigIntで無駄なコピーが発生するというRustで気をつけるべき技術的な問題の指摘にみえる
そして回避コードもきちんと示しているのでそういう書き込みは歓迎

**デフォルトの名無しさん** · 2022/06/05(日) 21:53:01.43

>>470
何のメリットもなく汚くしてるだけだから受け入れられないという話だったんだが

**デフォルトの名無しさん** · 2022/06/05(日) 22:11:06.61

ジェネリックのフィボナッチや
ジェネリックのカウントアップみたいな
架空のユースケースの話題はもういいよ

**デフォルトの名無しさん** · 2022/06/05(日) 22:14:01.51

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=41e1df59aeafe6f45fccaa192941d6d1

iter1とiter2は>>295からの引用
Ryzen 7 3700Xで計測
ジェネリクスへのこだわりを捨てればこのくらいは速くできるよ

fib_iter1 time: [7.2754 ms 7.2824 ms 7.2907 ms]
Found 2 outliers among 100 measurements (2.00%)
1 (1.00%) high mild
1 (1.00%) high severe

fib_iter2 time: [7.8536 ms 7.8678 ms 7.8818 ms]

fib_biguint time: [4.9757 ms 4.9784 ms 4.9812 ms]
Found 5 outliers among 100 measurements (5.00%)
5 (5.00%) high mild

Playgroundでもベンチマークできればいいのになあ

**デフォルトの名無しさん** · 2022/06/05(日) 22:14:34.17

「RustとC++を学ぼうと思ってるプログラミング初心者です。」(架空)

**デフォルトの名無しさん** · 2022/06/05(日) 22:24:27.68

どの場でも同じだが
「技術的な話題と技術的な指摘」
「他者の話題と他者への攻撃」
この違いがわからず後者を行なうダメ人間のせいで場が荒れる

**デフォルトの名無しさん** · 2022/06/05(日) 22:25:12.37

>>475
それは流石に比べる対象が違うんじゃ？
ノンジェネリック版もイテレータを返すか
ジェネリック版をフィボナッチ数を直接返すようにして比べないと

**デフォルトの名無しさん** · 2022/06/05(日) 22:36:45.16

>>475
playgroundみたいな環境でベンチマークやれたとしても結果が安定しないのでは

**デフォルトの名無しさん** · 2022/06/05(日) 22:40:18.97

>>475
純粋にジェネリックか否かの比較をしたいならばadd_assignとaddの違いなども含めて条件を全て揃えたほうがよい
元がiter::successorsを使っているならば非ジェネリック版も同じくそれで揃えてみてはどうか

**デフォルトの名無しさん** · 2022/06/05(日) 23:17:38.06

>>478
>>480
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=4f477ec7bc08ea9f61f565c00beb0d19

ジェネリックなほうをできる限り揃えたけどこれでいいかい？
CheckedAddでadd_assignする方法だけ無さそうだったからアレになってるけど

fib_generic time: [7.4054 ms 7.4164 ms 7.4275 ms]
Found 1 outliers among 100 measurements (1.00%)
1 (1.00%) high mild

fib_biguint time: [4.9527 ms 4.9591 ms 4.9655 ms]

**デフォルトの名無しさん** · 2022/06/05(日) 23:34:45.61

>>477
> 後者を行なうダメ人間
そういうのは一定数いるからスルーしてくださいな...

**デフォルトの名無しさん** · 2022/06/06(月) 00:32:35.96

イテレータで計測してみたけど
>>295のoption::takeだとcloneしても速度変わらないな
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=283e5cd13159cab00fcc68d56952df01

**デフォルトの名無しさん** · 2022/06/06(月) 02:33:06.91

>>483
そういう比較はそれ以外の部分のコードを揃えないと何が要因なのか判断できないよ

**デフォルトの名無しさん** · 2022/06/06(月) 03:21:12.98

Rustってフィボナッチ専用言語みたいだな

**デフォルトの名無しさん** · 2022/06/06(月) 12:48:39.09

>>481
addがchecked_addになることで最適化が妨げられてるみたい

結局複オジが言ってたことは全部間違いだった

**デフォルトの名無しさん** · 2022/06/06(月) 14:47:49.79

premature optimizationとpremature abstructionの典型例

・具体的なユースケースを想定しない
・トレードオフを考えない
・誰も求めてない抽象化
・計測を伴わない思い込み最適化

コードの汚さと悉く間違った主張の根っこは同じ

**デフォルトの名無しさん** · 2022/06/06(月) 15:32:14.02

複オジのおかげでいろんな教訓が再認識できて良かったね
反面教師の鑑
めでたしめでたし

**デフォルトの名無しさん** · 2022/06/06(月) 15:53:42.58

>>487
なるほど
「早すぎる抽象化 × 早すぎる最適化 => 汚コード」ってことか
これは身に覚えがありまくる

**481** · 2022/06/06(月) 16:16:13.39

>>486
正確に言えば
問題はCheckedAdd::checked_add()はselfもotherも参照で取るから、BigUintだと内部で1回clone()されてしまうということなのよね
一方でadd_assignは(桁があふれない限り)in-placeにやるから、その分のコストが発生しない
だから(compiler optimizationという意味での)最適化以前の問題だよ

https://mevius.5ch.net/test/read.cgi/tech/1509028624/153
↑のコードも参考にどうぞ
C++で二項演算子をオーバーロードするときのイディオムです
これを思い出しながら書きました

**デフォルトの名無しさん** · 2022/06/06(月) 16:52:12.73

>>490
ソース見るところ勘違いしてた
確かにaddでも&self使えばclone入るからchecked_add並みに遅くなった

checked_addにownedのselfを取るバージョンが追加されれば改善するだろうけど
trait定義からして対応するつもりのないユースケースかもね

**デフォルトの名無しさん** · 2022/06/06(月) 16:57:14.59

>>491
CheckedAddAssignを導入すれば全て解決しそうだな

**デフォルトの名無しさん** · 2022/06/06(月) 17:23:25.42

必要ならextension traitを書けばいい
そこまでしてジェネリックにする価値があるとは思えないけど

**デフォルトの名無しさん** · 2022/06/06(月) 18:19:44.52

リーナスさんから受けたパニックのありがたい指摘って結局どうなったん？

**デフォルトの名無しさん** · 2022/06/06(月) 20:58:23.31

放置されてんじゃないの？
コンパイラがパニック起こさないように変えられたって聞かないし

**デフォルトの名無しさん** · 2022/06/06(月) 21:04:20.00

パニックにならないオプションくらい作ってもいい気もするけどね

**デフォルトの名無しさん** · 2022/06/06(月) 21:29:53.43

パニック自体はもう１年前くらいに修正済み
今はv7 patchまで来ていて大きな懸念も出ていないから
そろそろマージされてもおかしくはない

**デフォルトの名無しさん** · 2022/06/06(月) 21:51:13.91

リーナスレベルに行く前に誰も問題視してなくて指摘もされてないんだろうか
みんなガバガバなんだな
panic前提のコーディング

**デフォルトの名無しさん** · 2022/06/06(月) 22:44:51.98

try_reserveはstabilizeされてるよ

**デフォルトの名無しさん** · 2022/06/06(月) 23:01:32.72

>>498
リーナスが最終承認だけするイメージなんかな？
LKML読めば分かるけど、普通にパッチ投げるたびに突っ込んでくるよ

**デフォルトの名無しさん** · 2022/06/06(月) 23:06:15.51

ジェネリックフィボナッチと同程度にどうでもいい

**デフォルトの名無しさん** · 2022/06/06(月) 23:15:40.43

>>481
1.5倍も差があるのは妙だな
Rustでは最適化されるのでジェネリックで書こうがそんな差は出ないはず
そのベンチマークの仕方がおかしい可能性があるので
ジェネリックか否か、check_addか＋か、Option利用か否か、など5つのコードで順に調べてみた

ベンチマーク使用コード
https://gist.github.com/rust-play/18d303c3ec79c19c4285ed190e5b2562
(1) ジェネリック + checked_add + Option + successors 版: 元の>>295と完全に同じコード
(2) BigUint + checked_add + Option + successors 版: (1)のTをBigUintへ
(3) BigUint + add + Option + successors 版: (2)のchecked_addを'+'へ
(4) BigUint + add + Option削除 + successors 版: (3)の変数Optionを削除
(5) BigUint + add + Option削除 + from_fn 版: (4)のsuccessorsをfrom_fnへ

結果
test bench_1 ... bench: 619,527 ns/iter (+/- 18,257)
test bench_2 ... bench: 620,293 ns/iter (+/- 23,787)
test bench_3 ... bench: 624,149 ns/iter (+/- 24,388)
test bench_4 ... bench: 626,810 ns/iter (+/- 20,343)
test bench_5 ... bench: 619,675 ns/iter (+/- 30,977)

結論
いずれも誤差の範囲でほぼ同一結果
Rustではジェネリックで書いても最適化される
BigUintでchecked_addやその結果のOptionを使っても最適化される

したがってi8からBigUintまで任意に動作する>>295のジェネリックコードで問題なし、となる

**デフォルトの名無しさん** · 2022/06/06(月) 23:58:37.28

>>502
Rust凄いな
ジェネリックもOptionも何でも最適化してくれるとは改めてRustの素晴らしさを実感

**デフォルトの名無しさん** · 2022/06/07(火) 00:13:51.07

>>502
そのやり方で差が出ないのはchecked_addと同じようにcloneが発生するタイプのaddが使われてるからだよ
ジェネリックにしても差が出ない場合もあれば差が出る場合もあるということ

**デフォルトの名無しさん** · 2022/06/07(火) 00:16:51.98

>>502
やはり同じになったか
既に>>478が指摘しているように元のコードとイテレータ同士で比較ベンチを取ろうとしないから>>475を怪しいと思ってた
ちゃんと比較ベンチすれば最適化されて同じ速さになることを知っての狼藉だったりして

**デフォルトの名無しさん** · 2022/06/07(火) 00:17:18.96

https://gist.github.com/rust-play/8caca28378745b36aaba5358d2a54fe8

test bench_1 ... bench: 426,714 ns/iter (+/- 5,563)
test bench_fast ... bench: 201,510 ns/iter (+/- 2,926)

Criterion の使い方が分からなかったのかな

**デフォルトの名無しさん** · 2022/06/07(火) 00:19:44.22

>>504
どういうこと？
具体的に>>502の各コードよりも速いコードを書けるってこと？
そのコードを示せない限り>>502のベンチ結果を覆せない

**デフォルトの名無しさん** · 2022/06/07(火) 00:35:03.04

>>506
君は全く別の問題にすり替えて誤魔化している
>>502のようにイテレーター同士でベンチマークをとるべき

**デフォルトの名無しさん** · 2022/06/07(火) 00:38:00.86

まーたすがすがしいまでの自演だなぁ

**デフォルトの名無しさん** · 2022/06/07(火) 00:39:26.17

>>507
>>504の指摘の何が分からないの？

**デフォルトの名無しさん** · 2022/06/07(火) 01:10:53.92

https://gist.github.com/rust-play/bde9b95f9bfe4de77fad841db30222c7

test bench_1 ... bench: 420,671 ns/iter (+/- 53,102)
test bench_fast ... bench: 219,091 ns/iter (+/- 1,147)

こんな汚ないことしてまでイテレータになんかしたくないんだけど
どうせ次の文句も大体予想付くし

**デフォルトの名無しさん** · 2022/06/07(火) 01:35:52.48

この件はRustにとって重要なことだから口を挟むが、
Rustではジェネリックで書いてもmonomorphizationによって各型で書いた時と同じコードになる。
だから標準ライブラリの大半はジェネリックに書かれている。
そしてSomeなどのOptionは最適化できる時は綺麗に消えるため、
BigIntのchecked_addのように常にSomeを返す時も最適化でOptionは消えると考えられる。
いずれも抽象的に書けるのに動かすとC並に速いというRustの長所である。

つまり、>>502の結果が出たことはそれらが実証付けられたことになる。

しかし、以前からジェネリックは無駄とか遅いとかRustの長所に反する主張をする人がいるので気になっていた。
今回もRustのジェネリックは遅いと主張するために、
>>506のように、完全に異なるもの同士を比較したり、
>>511のように、Rcを返すという別仕様のものにしてまで、ジェネリックは遅いと主張し出した。
反Rustか反ジェネリックの立場なのかもしれないが、そういう捏造や詐欺のようなことはよくない。

**デフォルトの名無しさん** · 2022/06/07(火) 01:49:10.77

>>512
同意

**デフォルトの名無しさん** · 2022/06/07(火) 03:36:34.68

>>512
ジェネリクスが無駄だの遅いだのはコード生成の話ではなくてコードのメンテナンスコスト含めた全体の話では

例えば今回ジェネリックなコードで無駄なcloneを避けるためには CheckedAddAssign といった trait を用意し、各整数型に実装するという余計な手間が発生する
また、各整数に追加のtraitを実装したとしても固定長の整数型ではすぐに桁あふれしてしまうから、実質BigUintの実装しか意味がないものになる
だったら最初からジェネリックにせずBigUintで実装するか、BigUintやBigIntといった桁あふれしない型だけを対象にすればよい

ジェネリクスの良さを語りたいならもっと良い例があるんじゃないの

**デフォルトの名無しさん** · 2022/06/07(火) 07:03:55.78

>>511
そのコードはイテレータ内部で無理にunwrapしているためこれだけでpanicしてしまう
let mut iter = fibonacci_biguint_iter();
let first = iter.next();
let second = iter.next();
実行結果
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:23:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
これでは反証コードになっていないので
ちゃんとimpl Iterator<Item = BigUint>を返すコードを書いたほうがいい

>>514
その無駄なcloneとは何？
ベンチ>>502のジェネリックコードを含めた5つのコードを見てみたが無駄なcloneは見当たらなかった
それらよりもベンチで速いコードが出てこない現状をみると無駄は無いのではないか
あと、BigUintを使うまでもない需要も多いのだからジェネリックに書かれたコード一つで十分と感じる

**デフォルトの名無しさん** · 2022/06/07(火) 08:13:15.84

>>503
それはLLVMのおかげじゃない？
他言語でできないRustならではの優位点てあったっけ？

**デフォルトの名無しさん** · 2022/06/07(火) 08:54:11.67

Rustで抽象オブジェクト作るのってどうやんの？

**デフォルトの名無しさん** · 2022/06/07(火) 08:59:47.84

>>517
Box<dyn ...>のこと？

**デフォルトの名無しさん** · 2022/06/07(火) 11:56:38.96

>>518
C系だと構造体にtypeフィールド作って定数入れてその定数の値に応じて呼び出す関数変えるみたいなことやるんだけど
インタプリタの動的オブジェクトみたいなもの
Rustでもtypeフィールで条件分岐するのが普通？

**デフォルトの名無しさん** · 2022/06/07(火) 12:28:57.89

>>519
その用法ならたぶんenumですかね
https://doc.rust-jp.rs/book-ja/ch06-01-defining-an-enum.html

**デフォルトの名無しさん** · 2022/06/07(火) 12:30:31.93

ファントムなんとかを使うんじゃないのか？

**デフォルトの名無しさん** · 2022/06/07(火) 12:50:46.76

抽象オブジェクトと検索して出てくる例みたいなのをRustでやるならこうだな

enum Object {
Integer(i32),
Float(f32),
文字列(String),
Null,
}
use Object::{Integer, Float, 文字列, Null};

impl Object {
fn hello(&self) {
match self {
Integer(i) => println!("Hello, Intger {i} です"),
Float(f) => println!("Hello, Float {f} です"),
文字列(s) => println!("こんにちは、文字列 {s} です"),
Null => println!("Nullです"),
}
}
}

fn main() {
let object_list = [Integer(12345), Float(67.89), 文字列("ABC".into()), Null];
for object in &object_list {
object.hello();
}
}

**デフォルトの名無しさん** · 2022/06/07(火) 13:15:30.50

gccではなくg++とかだとフィボナッチ数列とかは演算しないように最適化される場合がある。
Rustのようにイグノーベルの遊びのコンピューターサイエンスのようなコードをこねくり回して気持ち悪く長くて自己満足オナニーコードになるぐらいだったら
部分的にmasmで書いたほうがマシ（速度的にも、メンテナンス性も）
またRustはLLVMに執着しすぎてgccのような最適化はまだされてない、フィボナッチ数列とかのしょーもない一般的なアルゴリズムは
CPUキャッシュに乗るのにマシンコードのセクションの結果が64kbに成らなかったり

**デフォルトの名無しさん** · 2022/06/07(火) 13:48:18.23

>>620-522
ありがとう

**デフォルトの名無しさん** · 2022/06/07(火) 14:15:55.18

>>523
演算しないように最適化されるとか意味不明
演算はどこかで必ず発生する
コンパイル時点で演算してしまう定数化のことならばRustでも当然できる
const fn fibonacci(n: usize) -> usize {
const fn f(n: usize, a: usize, b: usize) -> usize {
match n {
0 => a,
1 => b,
_ => f(n - 1, b, a + b),
}
}
f(n, 0, 1)
}
const F77: usize = fibonacci(77);

**デフォルトの名無しさん** · 2022/06/07(火) 15:36:32.04

>>511
俺環の遅いマシンだと6倍近く速くなった
この差なら用途によっては汚くする価値が十分あるね

まあ実際のプログラムでBigUintのサイズまで一つ一つイテレータで返すような使い方をすることはまずないだろうけど

**デフォルトの名無しさん** · 2022/06/07(火) 15:42:23.15

>>511
コードが汚い上にget_mutが失敗してpanicする欠陥コードを恥ずかしげもなく披露できるもんだな

**デフォルトの名無しさん** · 2022/06/07(火) 17:49:46.06

>>525
だからそう言ってる、そして機能紹介は知ってることを言わなくてよいよ？コンパイル時実行とは違う。gcc系は数学的に既に答えが出るようなアルゴリズムを書いた場合に演算しないで低い桁で答えを持つ場合がある。
意味が分からないんだったら日本語から勉強しなおせ。それと汚いものを張り付けるな

**デフォルトの名無しさん** · 2022/06/07(火) 18:06:57.96

>>523
定数たたみ込みのことかな
試した限りでは gcc でも clang でも rustc でも最適化されて fib 呼び出しは消えているよ
どういうコードで問題おきるの？

gcc: https://godbolt.org/z/nx3hnsxTT
clang: https://godbolt.org/z/MYc7G9jeG
rustc: https://godbolt.org/z/x18ob3MjP

**デフォルトの名無しさん** · 2022/06/07(火) 18:10:22.54

>>523
あとrustがllvmに執着しているというのも間違いで
gccのcodegenを使えるようにするプロジェクトもあって活発に開発されてるよ
https://github.com/rust-lang/rustc_codegen_gcc

**デフォルトの名無しさん** · 2022/06/07(火) 18:17:47.44

>>524
>>620 よろすく

**デフォルトの名無しさん** · 2022/06/07(火) 20:22:53.88

フィボナッチなんて普通に解析解あるんだからそれ使えばいいじゃん

**デフォルトの名無しさん** · 2022/06/07(火) 20:28:59.38

ﾌｨﾎﾞﾅｯﾁよりﾎﾞｲﾆｯﾁを解読してくれ

**デフォルトの名無しさん** · 2022/06/07(火) 23:19:58.58

ボイニッチはどうせ創作ノートでしかないし

**デフォルトの名無しさん** · 2022/06/07(火) 23:25:02.45

>>532
フィボナッチは単なる題材に過ぎないことを理解できていないのはヤバいぞ
例えば>>529の定数畳み込みや>>502のジェネリックやOptionが最適化される話などが本題
単純だが単純過ぎない題材の例としてたまたまフィボナッチ数列が使われている

**デフォルトの名無しさん** · 2022/06/07(火) 23:57:19.63

ﾜｯﾁｮｲありスレに移住してここは複おじに明け渡してやったほうがいいのかもな

**デフォルトの名無しさん** · 2022/06/08(水) 00:55:31.29

>>536
複おじの意味がいまだにわからないが
ジェネリックよりも速いコードがあるならきちんと示そうぜ

>>506はイテレータと関数の異種比較のイカサマ
>>511はイテレータ同士の比較へ改善されたがイテレータの中のunwrapでpanicするマガイモノ
そんなデタラメばかりしていたら信頼を失うぜ

**デフォルトの名無しさん** · 2022/06/08(水) 01:35:00.04

>>537
>>481は？

**デフォルトの名無しさん** · 2022/06/08(水) 01:40:47.24

https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=5180fadf9fda409e0456042fc1bccd8e

遅くなるの分かりきってたから出し渋ったつもりだったけど普通に速かったわｗｗｗメンゴメンゴ

test bench_1 ... bench: 426,277 ns/iter (+/- 1,804)
test bench_fast ... bench: 350,928 ns/iter (+/- 2,760)

一応criterion版も貼っとく
>>502で提起されたベンチマーク不適切説の真偽が気になるなら是非実行してみてくれ
https://gist.github.com/rust-play/3bd45555b9e6faef2b1426712e4e7601

**デフォルトの名無しさん** · 2022/06/08(水) 02:05:38.58

>>539はin-placeなchecked_addを実現するtraitがないことで速度差大きくなってるものだよね

ジェネリクスが遅いと言ったときに、
ジェネリクスの機構自体による速度差と、ジェネリクスにまつわるエコシステムによる速度差という二通りの解釈があると思うけど、
>>537は前者のことを、>>539は後者のことを言っていて議論がかみ合っていないのではないか

ジェネリクスの機構だけの話をするなら前者の議論だけで良いけど、
メンテナンスコスト含めた実用性考えると後者の範囲も考える必要があるよね、
というのが>>514で言いたかったこと

**デフォルトの名無しさん** · 2022/06/08(水) 02:17:57.20

>>539
君のベンチはいつも何と何の違いを比較しようとしているのかよくわからない

一方で>>502は何と何を比較するのかを明確にした上で各項目毎に段階を経て比較しているから
仮にベンチで違いがあればその要因が明確となり知見が得られる比較となっている

君の投稿からは結果に対して何が要因なのか知見が全く得られない

**デフォルトの名無しさん** · 2022/06/08(水) 02:29:17.13

>>540
まず速度差がそのおっしゃっているchecked_addによるものなのかどうかを明確にしたほうが良いかと思う
>>502を見てみると(2)→(3)がchecked_addの有無になっているがベンチは同じ
その結果からchecked_addは関係ないのではないか？

**デフォルトの名無しさん** · 2022/06/08(水) 04:21:09.02

>>540
ジェネリックにやりたいならCheckedAddAssignを作ればいいんじゃん？
Rcのもジェネリックにもできるわけだし

**デフォルトの名無しさん** · 2022/06/08(水) 05:52:38.17

>>540
そもそもコードが汚いという指摘が発端なので
前者が論点だと思ってる人はいないと思うよ

**デフォルトの名無しさん** · 2022/06/08(水) 06:22:34.20

>>544
元と同一コードを含む5種類のベンチ>>502のコードを見たけど
特に汚いコードは見当たらないんじゃない？
もしあるならば具体的にどの部分なのかを言ったほうがいいと思うよ

**デフォルトの名無しさん** · 2022/06/08(水) 08:45:07.60

>>541
「checked_addしてから代入」と「add_assign」の比較だよ
で現状後者はジェネリックにやるために適切なtraitが無いから、
ジェネリックな関数では性能向上に限界があるよねって話
>>540の言う通り、ジェネリック関数とmonomorphized関数をの性能を比較したいわけじゃないよ

>>542
>>490,491でも出た通り、checked_addとadd(両辺とも参照の場合)はどっちもcloneが発生する
だから(2)を(3)にしても、遅いchecked_addを遅いaddで置き換えただけなので性能向上は無い
あとclone発生してるのはここね、docs.rsの[src]からたどれば&BigUint同士のaddがこのマクロで定義されているのが分かるはず
https://docs.rs/num-bigint/latest/src/num_bigint/macros.rs.html#91-107

**デフォルトの名無しさん** · 2022/06/08(水) 09:03:01.17

あんまり頑固になっても聞かなさそうなんでそろそろ妥協案でも

どうしてもジェネリックでやりたかったら、num::PrimIntでも使ってればここまでの批判は無かったんじゃないですかね
BigUint/BigIntは範囲から外れるけど、それはやっぱりそういうものなんですよ

**デフォルトの名無しさん** · 2022/06/08(水) 09:13:21.45

>>546
あなたのコード>>539もclone()しているから
1回あたりclone()が1回発生している点で同じではないかね
そこは重要なところだから曖昧な推測で済ませずに細かい差異でベンチマークを取ったほうがいいのではないか

**デフォルトの名無しさん** · 2022/06/08(水) 11:26:56.36

Rustが自由自在に書けるようなプログラマになりたがったンゴねえ
ワイは低脳だから躓いてるンゴ
例えば&'static TとT: 'staticの違いがなんかあるらしいんやがわからなかったンゴ
前者はプログラム終了時まで生きる変数の参照って意味で後者はもしTに参照があったらそれは'static以上生きるって解釈であってるんか？

**デフォルトの名無しさん** · 2022/06/08(水) 11:49:32.36

いや理解したんご
前者は参照型しか受け付けないけど後者はそれ以上の種類の型を受け付けるンゴねえ
さらに違いがあるかもだけど勉強進めるわ
なんでもなかった

**デフォルトの名無しさん** · 2022/06/08(水) 12:37:42.94

>>548
そのベンチが>>539のつもりなんだけど、これにどういう問題があって具体的には何をしろと？
from_fn使ってる分(5)のほうが近いから比較対象を(1)から(5)に変えろってこと？

というかそれが分かっているなら他人にやらせるんでなく自分で検証すればいいのでは？

**デフォルトの名無しさん** · 2022/06/08(水) 14:46:42.18

>>551
結局、何が原因なん？
ジェネリック？それともchecked_add？あるいは変数Some？まさかのswap？
Rustスレとしてはコードよりも原因を知りたい

**デフォルトの名無しさん** · 2022/06/08(水) 15:00:02.66

>>502
「1.5倍も差があるのは妙だな Rustでは最適化されるのでジェネリックで書こうがそんな差は出ないはず」
これがそもそもおかしい、最適化されようが何だろうが生成されるコードは違うのでMIRなりdisamなりでインストラクション単位で目視すれば一発だろ。ベンチを取る以前の思い込み低レベルな話
そしてほぼ最適化された無駄のないコードだったとしても
>>523
ここ5年程度のCPUでは64バイトのDSB境界を持つ小さなループ呼び出しなどが単一のμopsキャッシュに収まる場合があるがコードの配置によって異なり1.5倍程度の差が出ても不思議じゃない。
言ってるのに全く聞かない

**デフォルトの名無しさん** · 2022/06/08(水) 15:48:23.76

>>553
その件は1.5倍差あった>>481がイテレータと関数を比較するという大チョンボをしていたことが原因と判明済
そしてジェネリックか否か自体では速度に差が出ないことを>>502のベンチが証明済

**デフォルトの名無しさん** · 2022/06/08(水) 17:10:39.22

>>554
よく見ろ、それは>>475の話だ
>>481は両方とも(usize) -> BigUintな関数

**デフォルトの名無しさん** · 2022/06/08(水) 17:16:08.77

これだけ時間をかけても原因すら分からずノンジェネリックとの速度差を埋められない状況をコストとして認識できてないのが恐ろしい

**デフォルトの名無しさん** · 2022/06/08(水) 17:31:51.50

一般的に、数列を順に求めるイテレータと、
そのうちの特定の数だけを求める関数とでは、
オーダー問題もアルゴリズムも変わってくるため、
>>481はまた別の問題となっている。
イテレータ同士の比較で1.5倍となっていないことからも、
異なる問題であると理解できるはず。

>>556
ジェネリックとノンジェネリックに速度差が無いことは、
>>502で既に示されたのだから、
ジェネリックかどうかは一切関係ないと思う。
ジェネリックとは別の問題。

**デフォルトの名無しさん** · 2022/06/08(水) 18:18:03.20

>>557
>>502はジェネリックでも実現できるコードをノンジェネリックにしただけ

ノンジェネリックならadd_assign, mem::swap, cloneで>>502のいずれよりも速いコードが書けるが
ジェネリックだとchecked_addを使わざるを得ず同じことが実現できない

**デフォルトの名無しさん** · 2022/06/08(水) 18:32:47.55

>>537では「ジェネリックよりも速いコードがあるならきちんと示そうぜ」と言っていて
>>540の言う違いを理解している感じだったのに
いざ本当にコードが出てくるとジェネリクス自体のオーバーヘッドの話に限定して、差は無いと連呼

わざとやってんの？

**デフォルトの名無しさん** · 2022/06/08(水) 19:11:11.80

>>558
> ジェネリックだとchecked_addを使わざるを得ず同じことが実現できない

それは違うのではないか？
ジェネリックでも自由にCheckedAddAssign等を定義して実現することが可能という話が既に出ている >>492 >>543
一方でノンジェネリックで書いてもオーバフロー対策としてchecked_addは使わざるを得ない
つまりどちらが有利とか優れているとかいう問題ではない

**デフォルトの名無しさん** · 2022/06/08(水) 19:45:52.60

>>560
他人の意見を鵜呑みにしてないでやってみれば？
俺はちょっと試してみたけど結局無理だと確信したよ

**デフォルトの名無しさん** · 2022/06/08(水) 19:54:30.37

CheckedAddAssignの定義難しいよね
cloneを減らせるうまい定義見せて欲しい

**デフォルトの名無しさん** · 2022/06/08(水) 19:58:01.42

>>560
> 一方でノンジェネリックで書いてもオーバフロー対策としてchecked_addは使わざるを得ない
つまりどちらが有利とか優れているとかいう問題ではない

BigUintの場合はオーバーフローを想定しなくて良いからただのAddAssignで良いよね
ジェネリックな実装の場合は考慮すべき事項が増えるというハンデを抱えている

**デフォルトの名無しさん** · 2022/06/08(水) 20:09:35.76

基地同士の喧嘩おもすれー

**デフォルトの名無しさん** · 2022/06/08(水) 21:16:33.76

ジェネリックでなくても各i8版～u128版でchecked_add要るんじゃね？

**デフォルトの名無しさん** · 2022/06/08(水) 21:31:30.99

>>560
CheckedAddAssignはAddAssignと同じようには実現できないよ
速度差は他の方法で工夫すれば埋めることは不可能ではない

**デフォルトの名無しさん** · 2022/06/08(水) 22:52:52.99

このままでは誰も気付かなさそうなのでここでネタばらし
>>539のcriterion版ですがこちらで動かすとこうなりました

fibonacci_iter_1 time: [7.3605 ms 7.3655 ms 7.3711 ms]
Found 9 outliers among 100 measurements (9.00%)
1 (1.00%) high mild
8 (8.00%) high severe

fibonacci_biguint_iter time: [7.5944 ms 7.5967 ms 7.5992 ms]
Found 2 outliers among 100 measurements (2.00%)
1 (1.00%) high mild
1 (1.00%) high severe

同程度に遅くなってしまいました
理由は>>548の通り、せっかく減らしたcloneをイテレータ化するために戻さざるを得なかったからです

一見非ジェネリックのほうが速い結果が出たのは、criterion版がN=50000としていたのに対して、
test crate版は最初に貼られたN=10000から変えずにやっていたためでした
criterion版をN=10000で、test crate版をN=50000で計測してみると大体同じような結果になりました
N<2^15あたりまでは非ジェネリックのほうがちょっとだけ速いみたいですが、まあ誤差の範疇かと思います

そういうわけで>>539で非ジェネリックのほうが速いと主張したのは嘘です
本気で信じちゃった人はごめんね

最初はcriterionとtest crateの差だと早とちりしたため、ベンチマーク不適切説とか勿体ぶった書き方をしてました
>>502で根拠も無く疑いをかけたのに対するカウンターのつもりで黙ってたんですが、不発になっちゃいました
まあでもtest crateってwarm upもしないしサンプル数固定だし、その結果ひどい場合だと>>511なんか相対誤差10%超えてるし
criterion使ったほうがいいよってのは大筋では間違ってないよね

最後に+=でイテレートするこれだけ貼っとくから
某おじはこれに相当する性能のジェネリックなイテレータが書けるまでそういったクソどうでもいい執着に人を付き合わせるんじゃないぞ
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=76cd0aad53f19888900a4b450fd078c5

**デフォルトの名無しさん** · 2022/06/08(水) 23:10:54.19

Rust使うやつは全員クズ

**デフォルトの名無しさん** · 2022/06/08(水) 23:14:19.56

ゴミみてぇに使いにくい

**デフォルトの名無しさん** · 2022/06/08(水) 23:33:46.23

>>567
ジェネリックは遅くて使い物にならずRustはクソ言語のいい流れが出来ていたのに邪魔すんなボケ