flt2dec: replace for loop by iter_mut #144205
Conversation
|
rustbot has assigned @workingjubilee. Use |
rustbot
added
S-waiting-on-review
hkBst
changed the title
hkBst
changed the title
hkBst
changed the title
|
Performance related so isolating it for the usual reasons, though it's unclear how much it matters. @bors r+ rollup=never |
bors
added
S-waiting-on-bors
library/core/src/num/flt2dec/mod.rs
Outdated
| for j in i + 1..d.len() { | ||
| d[j] = b'0'; | ||
| } | ||
| d.iter_mut().skip(i + 1).for_each(|c| *c = b'0'); |
There was a problem hiding this comment.
I don’t think this is clearly better or worse than before. But how about d[i+1..].fill(b'0')?
There was a problem hiding this comment.
That would be even better. I added it as an option to my bench crate, and performance on eu dev machines looks like this:
For aarch64:
test bench_round_up_fill ... bench: 974,458.62 ns/iter (+/- 17,236.78)
test bench_round_up_for ... bench: 1,055,622.70 ns/iter (+/- 2,128.75)
test bench_round_up_iter ... bench: 855,721.80 ns/iter (+/- 2,159.27)
For x86_64:
test bench_round_up_fill ... bench: 730,473.60 ns/iter (+/- 393.90)
test bench_round_up_for ... bench: 730,497.57 ns/iter (+/- 894.02)
test bench_round_up_iter ... bench: 740,172.60 ns/iter (+/- 954.45)
There was a problem hiding this comment.
On aarch the (+/-) is always strangely large.
There was a problem hiding this comment.
I suspect your benchmarks are reading tea leaves, not nailing down meaningful differences, because at least the iter_mut().skip() version should also be readily identifiable as equivalent to memset. Consider checking if one variant calls memset and the other doesn’t — if memset vs inline loop makes a real difference then any changes here will be extremely fragile as they depend on loop idiom recognition working or not working for this loop (which may also differ between isolated benchmark of this one function vs. benchmark of the whole flt2dec rabbit hole).
There was a problem hiding this comment.
Oh. I looked at the codegen in your godbolt link and both variants you tried already get turned into memsets. The reason why they benchmark differently is that your benchmark runs on a 100k character buffer filled with '9's so the cost is dominated by the initial "scan backwards for first non-9" part instead. I don't know why the phrasing of the memset makes a difference for codegen in that part of the function, but now I really don't trust the numbers nor do I have faith that this will at all reproduce in the context of the flt2dec routines. The actual buffer size is orders of magnitude smaller, effects on other arms of this match aren't benchmarked at all, and if it's weird spooky action at a distance that affects the codegen for the rposition loop, then inlining it into the callers may have similarly unpredictable effects.
There was a problem hiding this comment.
All of these concerns could be avoided by benchmarking a full trip through the formatting machinery. I appreciate that it's difficult to find an input that hits the path you're interested in and makes that piece of the code hot enough to get a measurable signal. But the "easier" alternative of reducing to the smallest possible benchmark and putting it a microscope can waste your time in other ways!
There was a problem hiding this comment.
If I reduce length to 10, then I get:
Aarch64:
test bench_round_up_fill ... bench: 14.86 ns/iter (+/- 0.01)
test bench_round_up_for ... bench: 16.07 ns/iter (+/- 0.01)
test bench_round_up_iter ... bench: 16.07 ns/iter (+/- 0.06)
X86_64:
test bench_round_up_fill ... bench: 10.47 ns/iter (+/- 0.01)
test bench_round_up_for ... bench: 12.85 ns/iter (+/- 0.02)
test bench_round_up_iter ... bench: 9.84 ns/iter (+/- 0.07)
There was a problem hiding this comment.
I still don't know if those numbers are at all meaningful, but at least they no longer give a reason to not use the fill version for the readability win, I guess?
|
@bors r- |
bors
added
S-waiting-on-author
rust-cloud-vms
bot
force-pushed
the
flt2dec
branch
from
67b272a to
f147716
Compare
|
assuming this doesn't magically fail tidy @bors r+ |
bors
added
S-waiting-on-bors
flt2dec: replace for loop by iter_mut Perf is explored in #144118, which initially showed small losses, but then also showed significant gains. Both are real, but given the smallness of the losses, this seems a good change.
|
I think queue is very borked |
|
@bors retry r- (manual status refresh, maybe github outage yesterday?) |
bors
added
S-waiting-on-author
|
@bors r=workingjubilee |
bors
added
S-waiting-on-bors
flt2dec: replace for loop by iter_mut Perf is explored in #144118, which initially showed small losses, but then also showed significant gains. Both are real, but given the smallness of the losses, this seems a good change.
Perf is explored in #144118, which initially showed small losses, but then also showed significant gains. Both are real, but given the smallness of the losses, this seems a good change.