Optimize break patterns

[zhangyunhao116]

Use wyrand instead of calling XORSHIFT 2 times in break patterns for the 64-bit platform. The new PRNG is 2x faster than the previous one.

Bench result(via https://gist.github.com/zhangyunhao116/11ef41a150f5c23bb47d86255fbeba89):

old                     time:   [1.3258 ns 1.3262 ns 1.3266 ns]
                        change: [+0.5901% +0.6731% +0.7791%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 13 outliers among 100 measurements (13.00%)
  7 (7.00%) high mild
  6 (6.00%) high severe

new                     time:   [657.65 ps 657.89 ps 658.18 ps]
                        change: [-1.6910% -1.6110% -1.5256%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 6 outliers among 100 measurements (6.00%)
  2 (2.00%) high mild
  4 (4.00%) high severe

[rustbot]

r? @scottmcm

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[scottmcm]

I'm going to flip this over to the actual lib team, not me, since I don't know what the algorithms policy is for stuff like this
r? rust-lang/libs

(I also wonder if 64-bit randomness is even all that useful here, since the odds of someone sorting more than 2³² items seems incredibly low, and if they're really sorting/selecting more, maybe breaking patterns in "only" the local over-4GB-of-RAM-anyway area might be sufficient.)

[zhangyunhao116]

Thanks! Agree that the length of the slice greater than 2^32 is a rare case, but the wyrand(generate 64-bit) is even 10% faster than the XORSHIFT(generate 32-bit) in the 64-bit platform. It might be better if we could use the faster algorithm and still support this rare case.

[cuviper]

Did you consider the 64-bit version of xorshift? (<<13; >>7; <<17) With your benchmark setup, 64-bit xorshift performs almost the same as the wyrand version on my system. I'd feel more comfortable staying in the same PRNG family, rather than introducing any uncertainty around the wyrand unlicense. (Which may be fine, but we have to figure that out.)

In break_patterns these calls are also repeated in a short loop, mixed with other operations, so it's not obvious to extrapolate from your benchmark to how that performance will play out in reality.

[zhangyunhao116]

I think using the 64-bit version of the XORSHIFT is good. On my server, the WYHASH is just 40ps (about 5%~10%) faster than it. Considering gen_usize is not a hot spot, using the same algorithm is an acceptable way.

[cuviper]

@bors r+ rollup=never (for perf)

[bors]

📌 Commit e107ca0 has been approved by cuviper

It is now in the queue for this repository.

[bors]

📌 Commit e107ca0 has been approved by cuviper

It is now in the queue for this repository.

[bors]

⌛ Testing commit e107ca0 with merge 6ffabf3...

[bors]

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing 6ffabf3 to master...

[rust-timer]

Finished benchmarking commit (6ffabf3): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.3%	[-2.3%, -2.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.3%	[-2.3%, -2.3%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-4.9%, -1.7%]	15
All ❌✅ (primary)	-	-	0

[scottmcm]

Wow! Are those cycle results legit? What's rustc sorting to get that?

[cuviper]

I think that may be recovering from a fluke in the prior cycles comparison that a regressed by the same amount.