[過去ﾛｸﾞ] Rust part15 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
539(5): 2022/06/08(水)01:40 ID:C5b6ywPX(1/6) AAS
外部ﾘﾝｸ:play.rust-lang.org
遅くなるの分かりきってたから出し渋ったつもりだったけど普通に速かったわｗｗｗメンゴメンゴ
test bench_1 ... bench: 426,277 ns/iter (+/- 1,804)
test bench_fast ... bench: 350,928 ns/iter (+/- 2,760)
一応criterion版も貼っとく
>>502で提起されたベンチマーク不適切説の真偽が気になるなら是非実行してみてくれ
外部ﾘﾝｸ:gist.github.com
546(1): 2022/06/08(水)08:45 ID:C5b6ywPX(2/6) AAS
>>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がこのマクロで定義されているのが分かるはず
外部ﾘﾝｸ[html]:docs.rs
547: 2022/06/08(水)09:03 ID:C5b6ywPX(3/6) AAS
あんまり頑固になっても聞かなさそうなんでそろそろ妥協案でも
どうしてもジェネリックでやりたかったら、num::PrimIntでも使ってればここまでの批判は無かったんじゃないですかね
BigUint/BigIntは範囲から外れるけど、それはやっぱりそういうものなんですよ
551(1): 2022/06/08(水)12:37 ID:C5b6ywPX(4/6) AAS
>>548
そのベンチが>>539のつもりなんだけど、これにどういう問題があって具体的には何をしろと？
from_fn使ってる分(5)のほうが近いから比較対象を(1)から(5)に変えろってこと？
というかそれが分かっているなら他人にやらせるんでなく自分で検証すればいいのでは？
555: 2022/06/08(水)17:10 ID:C5b6ywPX(5/6) AAS
>>554
よく見ろ、それは>>475の話だ
>>481は両方とも(usize) -> BigUintな関数
567(4): 2022/06/08(水)22:52 ID:C5b6ywPX(6/6) AAS
このままでは誰も気付かなさそうなのでここでネタばらし
>>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
省15
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.042s