Remove manual unrolling from slice::Iter(Mut)::try_fold

[scottmcm]

While this definitely helps sometimes (particularly for trivial closures), it's also a pessimization sometimes, so it's better to leave this to (hypothetical) future LLVM improvements instead of forcing this on everyone.

I think it's better for the advice to be that sometimes you need to unroll manually than you sometimes need to not-unroll manually (like #64545).

---

Final perf comparison: #64600 (comment)

---

For context see #64572 (comment)

[scottmcm]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 38d8c8d with merge dd115ba...

[bors]

☀️ Try build successful - checks-azure
Build commit: dd115ba

[rust-timer]

Queued dd115ba with parent eceec57, future comparison URL.

[rust-timer]

Finished benchmarking try commit dd115ba, comparison URL.

[nnethercote]

This change gets roughly half the improvements that the commit in #64572 gets.

[bluss]

I think that unrolling would eventually have to go and be removed from libcore, I was just hoping the compiler would catch up and be able to unroll loops with multiple exits itself. Unrolling should ideally belong to the compiler, so it can make the decision about when to duplicate code. I haven't revisited that, so for all I know llvm could have learned this by now. [Edit: checked -- rustc nightly does not unroll such things by itself right now either. I wonder if this multiple exit improvement means that things are on the way..? No clue]

This seems like a situation where it's easy to find both good and bad cases. Things like scans through bytes for parsing with a simple predicate benefit a lot from unrolling in all/find etc.

[scottmcm]

Ok, it seems like the inclination is that we should do this so I've turned this into a "real" PR.

I do think it's better for the advice to be that sometimes you need to unroll manually than you sometimes need to not-unroll manually, though I certainly with LLVM was better at these cases.

I'm not sure who should approve this -- does it need libs sign-off?

[timvermeulen]

Couldn't you just remove the try_fold and fold overrides entirely? They seem to now mirror the default implementations. And I think there's manual unrolling going on in the DoubleEndedIterator impl, too.

[scottmcm]

@bors try @rust-timer queue

(I'm curious to see the new self-profile results, and want to make sure that removing the overrides still keeps the gain here -- it might mean more work to eliminate !s.)

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 6ac64ab with merge 8be3622...

[bors]

☀️ Try build successful - checks-azure
Build commit: 8be3622 (8be3622ad74755484fd9b9e401d0ee96837be244)

[rust-timer]

Queued 8be3622 with parent 66bf391, future comparison URL.

[rust-timer]

Finished benchmarking try commit 8be3622, comparison URL.

[bjorn3]

script-servo-opt regressed, the rest is positive or neutral.

[scottmcm]

Oh, interesting. script-servo-opt is new, right? I can't find it in the previous perf comparison...

[scottmcm]

New perf link (thank you, Mark-Simulacrum!) with self-profile results for both sides:
https://perf.rust-lang.org/compare.html?start=b4ba2a3953ea9ec28f01c314be315d46673bd782&end=8be3622ad74755484fd9b9e401d0ee96837be244

It looks like nearly all of the speedup for clap-rs-debug run clean is ~2.5s in LLVM_emit_obj (and ~0.3s in LLVM_make_bitcode). Any idea why this would be so much better there? I'd hypothesized that the closure might be getting inlined 5x even in debug, but based on a quick experiment (https://rust.godbolt.org/z/HmYVvd) that doesn't seem to happen. Since this PR still ends up using try_fold (unlike #64572), it doesn't feel like it should have had a major enough impact on the amount of code that's getting sent to LLVM to account for the size of the win.

And for script-servo-opt run baseline incremental it's LLVM_emit_obj that increased by ~13.5s with this change. Curious.

[bluss]

This change looks good to me, but I guess we are waiting for some discussion. I'll try to ask @Geal about nom performance and unrolling.

You know how much I would like to say we can just reimplement important stuff, like an unrolling slice iterator, outside libcore, but the libcore version is still tied up with unstable features like assume — unknown what impact they have as of current rustc version.

[Geal]

@bluss no issue for me, nom does not use try_fold nor try_rfold internally

[bluss]

It looks like it's not impossible for rustc to unroll an "Iterator::all" like loop. It just can't do it in the simplest forms that those loops take, for example not in for elt in v { .. }

I have some old alternative slice iterator code, and it can be automatically unrolled by the compiler. The code is here (github link to iter.rs) and there are benchmarks that show the unrolling on that specific branch. I haven't managed to reduce the loop that will unroll, though — maybe it's specific to the code in the benchmark? The compiler's unroll disappears if the special case .all() method is removed from that iterator, even though it only adds indirections (similar to using try_fold).

[scottmcm]

@bluss do you still have r+ here, or do I need to find a different reviewer for this?

[bluss]

@scottmcm I guess I do, but with the nominated tag I thought we were waiting for the libs team

[bluss]

@bors r+ rollup=never

[bors]

📌 Commit 6ac64ab has been approved by bluss

[bors]

⌛ Testing commit 6ac64ab with merge e0436d9...

[bors]

☀️ Test successful - checks-azure
Approved by: bluss
Pushing e0436d9 to master...

[bluss]

@Geal is now in the rustc 1.40.0-nightly (22bc9e1 2019-09-30) nightly. I'd be surprised if it didn't impact benches in some way