mbutrovich opened a new issue, #11451: URL: https://github.com/apache/arrow-rs/issues/11451
While reviewing #11425, @andygrove found two ways to make [`i256::div_rem`](https://github.com/apache/arrow-rs/blob/c7f60c612bd16ca5485cc9acddfd216c10ea9765/arrow-buffer/src/bigint/mod.rs#L488-L514) faster, measured in quick out-of-tree tests: - An `i128` fast path, taken when both operands fit in `i128`, was 2.3x to 3.4x faster on such operands. - [`bits`](https://github.com/apache/arrow-rs/blob/c7f60c612bd16ca5485cc9acddfd216c10ea9765/arrow-buffer/src/bigint/div.rs#L50-L58), [`add_assign` and `sub_assign`](https://github.com/apache/arrow-rs/blob/c7f60c612bd16ca5485cc9acddfd216c10ea9765/arrow-buffer/src/bigint/div.rs#L213-L221) in `div.rs` are not `#[inline]`. `i256::div_rem` is `#[inline]` and `div::div_rem` is generic, so both are compiled in the calling crate, but these non-generic helpers are not available for inlining there unless the build uses LTO. Without LTO, each division made out-of-line calls to them and was about 20% slower when the divisor fit in a `u64`. ### Describe the solution you'd like 1. Add `#[inline]` to `bits`, `add_assign` and `sub_assign`. 2. Add the `i128` fast path. Each change would report before and after numbers from the `Decimal256` cases in the `cast_decimal` benchmark (#11426) and the `decimal_arithmetic` benchmark (#11427). Those benchmarks build as their own crates, so they show the cross-crate inlining effect. They include values that fit in `i128` and values that don't, which shows what the fast-path check costs for wide values. ### Additional context The numbers above are from quick out-of-tree tests, not the in-repo benchmarks. -- 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]
