mbutrovich opened a new pull request, #11457: URL: https://github.com/apache/arrow-rs/pull/11457
# Which issue does this PR close? - Part of #11451. # Rationale for this change See #11451. I'm opening this as a draft to discuss whether the gain is worth it and where the remaining cost in `i256` division is. # What changes are included in this PR? This PR adds `#[inline]` to `bits`, `add_assign` and `sub_assign` in `arrow-buffer/src/bigint/div.rs`. In the `i256` bench binary on `main`, the bench crate's copy of `div_rem::<4>` calls `bits` twice and `add_assign` and `sub_assign` once each, out of line. With this change those calls and the three symbols are gone. `div_rem_word` is already inlined. # Are these changes tested? The existing `bigint` tests cover these functions. The change doesn't alter behavior. Benchmarks on an Apple M5 Max (arm64), from `cargo bench -p arrow-buffer --bench i256 -- i256_div_rem`, compared against a saved baseline from `main` in three runs: | Bench | `main` | This PR | Change | |---|---|---|---| | `i256_div_rem small divisor` | 15.94 us | 15.37 us | -3.5% to -3.8% (p = 0.00) | | `i256_div_rem small quotient` | 16.42 us | 15.42 us | not significant (p = 0.18 to 0.31) | That's smaller than the 20% in #11451. On arm64, `div_rem::<4>` also makes four calls to `___udivti3`. They come from `div_rem_word` ([div.rs](https://github.com/apache/arrow-rs/blob/9c07b17255ee65a70c1885368c1d91ca737521de/arrow-buffer/src/bigint/div.rs#L182-L211)), which uses a `div` instruction through inline assembly on x86_64 but computes `u128 / u128` on other targets. LLVM can't prove the quotient fits in 64 bits, so it calls the 128-bit division routine. I haven't profiled how much of the time that accounts for. Numbers from x86_64 would show whether the `#[inline]` change helps more there. # Are there any significant user-facing changes? No. ## AI Disclosure I wrote this PR with help from Claude but understand and support the core approach, implementation, and test coverage. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
