Decimal Mul/Div kernels - #9221
Conversation
Merging this PR will degrade performance by 3.86%
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing 
Footnotes
|
|
I think we should make codspeed tests slightly smaller |
d6301ef to
d68078b
Compare
d68078b to
e34ca33
Compare
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
Signed-off-by: Matt Katz <mhkatz97@gmail.com>
ee1a14d to
ad8336d
Compare
Adds native
MulandDivexecution for decimal arrays, completing the operator set that #8724 started with Add/Sub.p + 1s2p + 12sp + s + 4s + 4Execution
Lanes run at a working width from
decimal_numeric_work_dtype, then narrow to the result's own storage width. The two widths are not always the same: Mul's intermediate is the result itself, but Div scales the dividend by10^result_scalebefore dividing and so needs room forp + |result_scale|digits. A negative result scale scales the divisor instead.DecimalOpConstants<W>hoists the per-execution constants — the result-precision bounds and the two division scale factors — out of the lane loop.Every lane is checked at the working width.
DecimalArraydoes not validate its stored values against the declared precision, so an out-of-precision value can reach a kernel and must not be able to overflow it;test_decimal_value_outside_working_width_errorshas depended on that behaviour since #8724. Overflowing the result precision on a valid lane is an error, as is division by zero; invalid lanes never error.