Add a != check to ChunkedBitSet::union.

[nnethercote]

It's a big speed win for cranelift-codegen-0.119.0.

r? @Zalathar

[nnethercote]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 701ca72 (701ca7229fdda54e3b2aaf5d347786d78565ec43, parent: 2300c2aef7dbc2a7bbbeaa9894d07d459abd9bc6)

[Zalathar]

For future work, we could hypothetically get even more clever, and try to start the bitwise_changes check from where the equality check failed (for suitable operators).

But that might not be worth the extra implementation complexity (or might even reduce the benefit of the equality check).

[rust-timer]

Finished benchmarking commit (701ca72): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-4.7%	[-9.6%, -1.3%]	6
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	1
All ❌✅ (primary)	-4.7%	[-9.6%, -1.3%]	6

Max RSS (memory usage)

Results (primary 2.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Cycles

Results (primary -3.3%, secondary 2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.7%	[2.7%, 2.7%]	1
Improvements ✅ (primary)	-3.3%	[-3.5%, -3.1%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.3%	[-3.5%, -3.1%]	2

Binary size

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

Bootstrap: 472.507s -> 474.412s (0.40%)
Artifact size: 388.12 MiB -> 388.13 MiB (0.00%)

[nnethercote]

For future work, we could hypothetically get even more clever, and try to start the bitwise_changes check from where the equality check failed (for suitable operators).

But that might not be worth the extra implementation complexity (or might even reduce the benefit of the equality check).

Interesting idea! I tried it out, with code like this:

let i = match iter::zip(&self_chunk_words[0..num_words],&other_chunk_words[0..num_words],).position(|(a, b)| a != b){Some(i) => i,None => continue,// all elements equal, nothing more to do};let op = |a, b| a | b;if !bitwise_changes(&self_chunk_words[i..num_words],&other_chunk_words[i..num_words],
op,){continue;}// ... do the mutation ...

And it ended up being a significant slowdown. I think because that iter::zip/position loop is much less optimized than simple slice comparison, which would use something like memcmp.

[nnethercote]

I have update the code a little to include some refactoring.

[Zalathar]

Looks good, thanks!

@bors r+

[bors]

📌 Commit ad8b2e0 has been approved by Zalathar

It is now in the queue for this repository.

[nnethercote]

Uh, so what's happening? I'm generally capable of managing my own PRs. Have you taken this over now? Can I do anything with it or will that mess things up?

[Zalathar]

Ah, I was thinking it would be helpful to rebase this, but maybe I ended up causing more confusion.

I've force-pushed back to your original commit, and I won't touch this any more, so please feel free to resolve it yourself and reapprove.

[nnethercote]

Ok, thanks.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[nnethercote]

I have rebased.

@bors r=Zalathar

[bors]

📌 Commit 6048182 has been approved by Zalathar

It is now in the queue for this repository.

[bors]

⌛ Testing commit 6048182 with merge 4f08307...

[bors]

☀️ Test successful - checks-actions
Approved by: Zalathar
Pushing 4f08307 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 5413f7d (parent) -> 4f08307 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 4f08307f6efdbca86d27beecd257fad9913192e9 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-x86_64-mingw: 8717.0s -> 10591.0s (21.5%)
2. dist-x86_64-apple: 6952.6s -> 8058.0s (15.9%)
3. dist-apple-various: 3943.6s -> 4517.6s (14.6%)
4. dist-i686-mingw: 9549.0s -> 10751.7s (12.6%)
5. x86_64-mingw-2: 7527.0s -> 8388.0s (11.4%)
6. pr-check-1: 1517.4s -> 1657.6s (9.2%)
7. x86_64-gnu-llvm-20: 2673.5s -> 2435.8s (-8.9%)
8. x86_64-mingw-1: 10391.2s -> 11265.4s (8.4%)
9. dist-ohos-aarch64: 4323.0s -> 4664.4s (7.9%)
10. x86_64-gnu-tools: 3392.1s -> 3650.3s (7.6%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (4f08307): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.9%, 2.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.5%	[-9.3%, -0.1%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.8%	[-9.3%, 2.9%]	9

Max RSS (memory usage)

Results (primary 2.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	16.6%	[16.6%, 16.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.9%	[-4.1%, -0.4%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.8%	[-4.1%, 16.6%]	4

Cycles

Results (primary -0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.2%	[3.2%, 3.2%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.1%	[-2.5%, -1.7%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.8%	[-2.5%, 3.2%]	4

Binary size

Results (primary 1.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Bootstrap: 475.31s -> 476.148s (0.18%)
Artifact size: 388.10 MiB -> 388.04 MiB (-0.01%)

[Mark-Simulacrum]

The one regression looks spurious, dropping the label.