jaideeppyne commented on PR #10567: URL: https://github.com/apache/arrow-rs/pull/10567#issuecomment-5207200070
### Re: measurable impact / `powi` once per array (@jhorstmann, @Jefffrey) **jhorstmann’s point is correct in structure:** for float↔decimal casts the scale factor is computed once per array (not per element); the hot loop is multiply/divide by that factor. **Official `cast_kernels` criterion run on this PR** (triggered via `run benchmark cast_kernels`, [completed bot report](https://github.com/apache/arrow-rs/pull/10567#issuecomment-5204840000) — comparing `0aa845f7` to merge-base `6b7d6b3` on `c4a-highmem-16` aarch64): | Benchmark | PR | main | Ratio (main/PR) | |-----------|-----|------|-----------------| | cast decimal128 to float64 | 27.1±0.02µs | 27.1±0.02µs | **1.00** (tie) | | cast decimal256 to float64 | **60.0±0.05µs** | 68.5±0.04µs | **1.14** (PR faster) | | cast float64 to decimal128(32, 3) | 34.4±0.05µs | 34.4±0.05µs | **1.00** (tie) | So end-to-end cast kernels: **no change on decimal128↔float**, **~14% faster on decimal256→float64** in that run. That is consistent with “powi once per array” — gains show up where the one-time scale setup is a larger fraction of work (e.g. decimal256 path), not as a per-element win. **On Jefffrey’s follow-up** (*same speedup by ensuring power is not in the hot loop*): fully agree as a kernel-structure goal. This PR only replaces the scale-power calculation with a LUT (issue #10523). If maintainers prefer closing #10523 as “not worth it” given mostly-neutral cast_kernels results, or want a follow-up that restructures the cast so scale is always outside any residual hot path, happy to adjust. ### Review replies (ethantang93) - Negative scales: **intentionally no LUT** → `powi` fallback (documented + tests split). - Test nit: split LUT vs fallback tests in latest push. -- 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]
