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/

**434** · 2022/06/04(土) 15:21:18.99

自演臭くなるからアレなんだけど
暇潰しに公式ドキュメントと照らし合わせて疑問に思ったから書き込んだだけで
ただの通りすがりだからね

**デフォルトの名無しさん** · 2022/06/04(土) 15:39:42.64

>>449
あれは何もかも自演に見えてくる病気な人による連投だから気にする必要なし
何でもかんでも自演だ！汚コードだ！と言うダメな人

**デフォルトの名無しさん** · 2022/06/04(土) 16:10:13.56

書いてあるコードよりましなコードを出せずに汚コードって呟くしかない可哀想な人は暖かくスルーしてやってくださいな

**デフォルトの名無しさん** · 2022/06/04(土) 16:13:38.80

>>448
汚いというならオマエのコードを出せとイキってたのに
実際にコードが出てきてダンマリ決め込んだタイミング・・・

ありえそう
変な初心者が来たなとは思ってたが・・・

**デフォルトの名無しさん** · 2022/06/04(土) 16:30:17.39

汚コードを連呼してる人が初めて出したコードがこれ。>>202
しかしアルゴリズムに問題があってフルボッコにされて撃沈。
汚コードを連呼の人が普段コードを示せない理由が判明してしまった事件。

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

うわーこれ確定じゃん
複くんRustなんかやめてネトサポやれば？

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

>フルボッコにされて撃沈。
主砲「Copyはディープで高コストだから避けるべき」発射！ ==> ドッカーンwww撃沈www

**デフォルトの名無しさん** · 2022/06/04(土) 23:12:57.28

真面目に書いとくとusizeみたいな数値プリミティブの場合はCopy前提で全く問題ないよ
気になる人はベンチにかけてね

**デフォルトの名無しさん** · 2022/06/04(土) 23:38:03.39

>>456
一般的にはその通り
しかし今回はusizeだとすぐ溢れるからBigUintなどを見越してのコードの話
>>202への批評内容はいずれもusizeでしか通用しないアルゴリズムをわざわざ採用したという点
一方で>>202が汚コードとみなした元のコードはusizeでもBigUintでもちゃんと動作するアルゴリズムになっていた

**デフォルトの名無しさん** · 2022/06/04(土) 23:52:08.43

汚コード連呼厨は信頼できない
代わりのコードをいつも出せない
珍しく出してきたら元より劣化してた

**デフォルトの名無しさん** · 2022/06/04(土) 23:57:58.57

最初のコードでだいたいあってるんですよ
それを君がずっと引っ掻き回してるだけ
最初からあるんだからわざわざ出す必要もない

>>427で終わってた話を>>428で誰も求めてないfindで書き直したり

**デフォルトの名無しさん** · 2022/06/05(日) 00:16:50.25

毎週This Week in Rustのリンクでも貼ればこのくだらない流れは終わるのだろうか

**デフォルトの名無しさん** · 2022/06/05(日) 00:46:34.90

ところでスライスへのfindメソッドなどの後付けはRustのorphan ruleを犯さずに可能なの？

**デフォルトの名無しさん** · 2022/06/05(日) 04:00:56.97

trait定義すればできる

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

> 誰も求めてないfindで書き直したり

そもそも、誰ももとめてない
「ぼくのかんがえたさいきょうふぃぼなっちいてれーた」
をどんだけ貼り付けたんだろうな彼はｗ

誰も求めてないものを必死でシコってるからうんざりなんよ

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

複クンはなぜ汚いと言われるのか理解しないね
言語やライブラリの制約で避けられないような汚なさならここまで言われない

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

シンプルに意図が伝わりやすい書き方が他にあっても
ぼくのかんがえたさいきょうのシコシココードを我慢出来ずに開陳しちゃうからここが汚部屋になる

**デフォルトの名無しさん** · 2022/06/05(日) 10:48:55.83

findバージョンで答えようとしたところで
>>427のレスがあったから「findでも行ける」に方向転換したんじゃね？
幼稚園児と同じでママン達に誉めて欲しかったのに
汚いと一蹴されて涙目

**デフォルトの名無しさん** · 2022/06/05(日) 10:54:21.85

>>460
ブログへのリンクやアップデートはややマンネリ気味だけど
今週のcrateはいつもチェックしてる

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

>>467
そういう話をしたいのにRustと関係ない話や批判で荒らす連中がうざい
Rustの話ならば最新動向から初心者の質問まで何でも歓迎
しかし他人叩きしている連中は邪魔

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

可読性や汎用性を犠牲にしてもfindがpositionより優位に速いとか
ユースケース次第ではデメリットを補うだけのメリットがあるなら多少汚くても受け入れられる
フィボナッチの>>202と比較対象の>>181や>>189も同様

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

速度はベンチを取ってから
ユースケースは具体的に示してから
そういうことを主張してください

そして本当に互いのやり方にメリデメがあると認めているのなら、>>295のような他人叩きはやめましょうね

**デフォルトの名無しさん** · 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回発生している点で同じではないかね
そこは重要なところだから曖昧な推測で済ませずに細かい差異でベンチマークを取ったほうがいいのではないか