Add Benchmarks for int_pow Methods.

[NCGThompson]

There is quite a bit of room for improvement in performance of the int_pow family of methods. I added benchmarks for those functions. In particular, there are benchmarks for small compile-time bases to measure the effect of #114390. I added a lot (245), but all but 22 of them are marked with #[ignore]. There are a lot of macros, and I would appreciate feedback on how to simplify them.

To run benches relevant to #114390, use ./x bench core --stage 1 -- pow_base_const --include-ignored.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cuviper (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[NCGThompson]

Surprisingly, at least on Aarch64, checked pow unwrapped is very slightly faster than wrapping pow, while checked pow unwrapped unchecked is among the slowest. I guessed the assume statement produced from the unwrap unchecked seems to be helping more than it is hurting. I found a way to unwrap it without generating an assume statement.

*option.as_slice().as_ptr().cast::<$t>()

When I benched it though, and it was significantly slower than the unwrap uncheck.

On Aarch64 but not x86_64, overflowing i128 is dramatically (~5x) slower than overflowing u128. This is because on Aarch64, signed overflowing multiply does a compuler-rt function call while unsigned overflowing multiply is inlined. I'll have to check what happens on other architectures with Compiler Explorer. To work around this, we can take advantage of the fact that any integer to an even power is non-negative. I've already wrote a similar algorithm in Rust before.

[NCGThompson]

./x fmt is the reason some pow_bench_template! calls are a single line and others have the arguments listed vertically. I know it is inconsistent. Should I leave it the way ./x fmt likes it or should I somehow override it?

[NCGThompson]

@cuviper Updated based on your feedback. I also rebased and force-pushed it.

[cuviper]

Looks good, thanks!

@bors r+ rollup

[bors]

📌 Commit c65c35b has been approved by cuviper

It is now in the queue for this repository.

[bors]

⌛ Testing commit c65c35b with merge 752baf0...

[rust-log-analyzer]

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[RUSTC-TIMING] process_spawning test:true 1.399
[RUSTC-TIMING] env test:true 1.565
[RUSTC-TIMING] stdbenches test:true 2.936
[RUSTC-TIMING] test test:true 15.804
##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
##[group]Clock drift check
  local time: Fri Jan 12 00:02:09 UTC 2024
  local time: Fri Jan 12 00:02:09 UTC 2024
Session terminated, killing shell... ...killed.
##[error]The operation was canceled.
Cleaning up orphan processes

[bors]

💔 Test failed - checks-actions

[cuviper]

@bors retry

[NCGThompson]

@bors retry

Is this definitely a random error, or could it have anything to do with my changes? If I interpreted the logs correctly, it was the drift test that failed, and that seems unrelated to the changes.

[cuviper]

This message comes up occasionally on that particular runner, unrelated to any PR changes:

##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.

[bors]

⌛ Testing commit c65c35b with merge 6029085...

[NCGThompson]

@cuviper Is there a way to run or view the results of the library benchmarks on all the platforms that the CI tests?

[bors]

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

[cuviper]

Most of the targets are cross-compiled in CI, and AFAIK we don't even run those benchmarks on native targets in CI. They're really only useful for developers to run.

For more holistic benchmarking, see https://perf.rust-lang.org/ (source /~https://github.com/rust-lang/rustc-perf)

[rust-timer]

Finished benchmarking commit (6029085): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

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

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.9%	[0.6%, 1.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.0%, -3.1%]	2
All ❌✅ (primary)	0.9%	[0.6%, 1.2%]	2

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)	-2.3%	[-3.1%, -0.4%]	5
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.3%	[-3.1%, -0.4%]	5

Binary size

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

Bootstrap: 666.002s -> 666.091s (0.01%)
Artifact size: 308.40 MiB -> 308.42 MiB (0.01%)