sdf-jkl commented on PR #11979:
URL: https://github.com/apache/arrow-rs/pull/11979#issuecomment-6498452900

   All nine bot comparisons have completed, including the additional SVE, SVE2, 
and Neoverse-V2 runs. The rewrite has substantial x86 wins, but the ARM results 
remain mixed.
   
   These compare the original #11467 head 
(`46ab603e26b22d444203d660602605e53a2a8733`) with this draft 
(`4641eda8ce81922fa2ce9ebf5143700a994b73c0`), using the unchanged `divisor` 
benchmark: all 48 cases per configuration, including unsigned, power-of-two, 
and operator controls.
   
   The table summarizes the signed `AddIndicator` cases for divisors **7 and 
13**. Values are approximate **original time / rewrite time**: above 1× is 
faster, below 1× is slower. Ranges span the two divisors, not confidence 
intervals.
   
   | Target | i32 division | i32 remainder | i64 division | i64 remainder |
   |---|---:|---:|---:|---:|
   | 
[x86-64](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6482666076) 
| 2.08–2.09× | 1.73–1.76× | 1.13× | 0.96× |
   | 
[x86-64-v2](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6482655787)
 | 1.85–1.97× | 1.81–1.87× | 1.16–1.18× | 1.70–1.72× |
   | 
[x86-64-v3](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6482656188)
 | 0.76–0.81× | 0.90–0.97× | 1.06–1.07× | 1.03–1.07× |
   | 
[x86-64-v4](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6482656534)
 | 0.91–0.92× | 0.92–0.93× | 1.27–1.28× | 1.34–1.35× |
   | [x86 
native](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6482667430) 
| 0.91–0.95× | 0.93–0.94× | 1.20–1.22× | 1.32–1.33× |
   | [ARM default 
(NEON)](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6482645745) 
| 0.88× | 0.85× | 0.99× | 0.76× |
   | [ARM 
+sve](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6483531605) | 
0.93× | 0.92× | 0.99× | 1.02× |
   | [ARM 
+sve2](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6483530355) | 
0.93× | 0.91× | 0.99× | 0.96–1.01× |
   | [ARM 
neoverse-v2](https://github.com/apache/arrow-rs/pull/11979#issuecomment-6483529193)
 | 0.96× | 0.96× | 0.99× | 1.06× |
   
   The x86 workers were Intel Xeon Platinum 8581C; all ARM workers were 
Neoverse-V2. Target flags were shared by both revisions.
   
   The new ARM runs reduce the default build's 31–32% extra time for i64 
remainder to near parity with SVE/SVE2, or a 1.06× gain with CPU tuning. 
However, i32 still takes approximately 8–10% longer with SVE/SVE2 and 4% longer 
with Neoverse-V2 tuning. There is no meaningful i64 division gain.
   
   Local cross-compilation of the actual benchmark (Rust 1.99.1 / LLVM 23.1.1, 
thin LTO) shows why enabling SIMD need not favor the rewrite: SVE supplies 
vector high multiplies to **both** versions. The original uses signed `smulh`; 
the rewrite uses unsigned `umulh` plus sign-mask correction. Default i64 
remainder is scalar, with four elements per iteration in the original versus 
one in the rewrite; SVE vectorizes both. These are local code-generation 
observations, not disassemblies of the bot executables; runner toolchain 
equivalence is unverified.
   
   These are single bot comparisons per configuration. Unchanged controls also 
move: Neoverse-V2 i32 operator remainder improves 1.77–1.79× for 7/13, SVE 
unsigned remainder-by-16 takes 8% longer, and the earlier AVX2 run has 
substantial control variation. Small gains need independent repeats, and not 
every timing change can be attributed to the rewritten arithmetic.
   
   My current conclusion is that this is a target-dependent optimization, 
rather than an established across-the-board improvement. The baseline/v2 i32 
and AVX-512 i64 wins are promising, but ARM and AVX2 need further investigation 
before recommending the unconditional rewrite.
   


-- 
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]

Reply via email to