Execute primitive numeric operators with RowFn - #9345
Conversation
Merging this PR will degrade performance by 7.14%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | mul_u8_nonnull |
162.4 µs | 192 µs | -15.39% |
| ❌ | Simulation | points |
162.3 µs | 191.2 µs | -15.14% |
| ❌ | Simulation | cold_misaligned[(64, 256)] |
4.4 ms | 5.1 ms | -14.91% |
| ❌ | Simulation | linestrings |
164.7 µs | 193.4 µs | -14.87% |
| ❌ | Simulation | polygons |
166 µs | 194.4 µs | -14.59% |
| ❌ | Simulation | two_vertex_lines |
279.1 µs | 326.1 µs | -14.41% |
| ❌ | Simulation | multipolygon_random_nulls |
745.7 µs | 864.8 µs | -13.77% |
| ❌ | Simulation | nullable_two_vertex_lines |
326 µs | 373.6 µs | -12.73% |
| ❌ | Simulation | list_i32_large |
214.1 µs | 245.3 µs | -12.72% |
| ❌ | Simulation | take_filter_list_slice_mask_random_indices[768, 50] |
210.5 µs | 239 µs | -11.93% |
| ❌ | Simulation | take_filter_list_random_mask_sequential_indices[768, 50] |
207.5 µs | 235.4 µs | -11.85% |
| ❌ | Simulation | take_filter_list_random_mask_sequential_indices[256, 50] |
211.4 µs | 239.7 µs | -11.82% |
| ❌ | Simulation | take_filter_list_small_random_mask_random_indices[256, 10] |
206 µs | 233.4 µs | -11.74% |
| ❌ | Simulation | take_filter_list_small_random_mask_random_indices[768, 10] |
214.2 µs | 242.4 µs | -11.65% |
| ❌ | Simulation | list_sum_small |
229.6 µs | 259.8 µs | -11.64% |
| ❌ | Simulation | take_filter_list_slice_mask_random_indices[256, 50] |
209.8 µs | 237.4 µs | -11.63% |
| ❌ | Simulation | take_filter_list_small_uncached_random_mask_random_indices[256, 10] |
205.8 µs | 232.8 µs | -11.6% |
| ❌ | Simulation | take_filter_list_nullable_random_mask_random_indices[256, 50] |
229.3 µs | 258.2 µs | -11.2% |
| ❌ | Simulation | take_filter_list_random_mask_random_indices[768, 50] |
228 µs | 256.6 µs | -11.16% |
| ❌ | Simulation | take_filter_list_small_uncached_random_mask_random_indices[768, 10] |
214.6 µs | 241.1 µs | -10.99% |
| ... | ... | ... | ... | ... | ... |
ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing ct/row-fn-numeric-operators (b7eb750) with ct/row-fn-framework (0eb4dd3)2
Footnotes
-
89 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
-
No successful run was found on
ct/row-fn-framework(219e00a) during the generation of this report, so edf8937 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
ab0697a to
b63ded4
Compare
## Rationale for this change Lets indexed lane sources return borrowed or otherwise non-`Copy` items. RowFn needs this for typed row inputs without adding a second kernel abstraction. - Progress towards: #9129 ## What changes are included in this PR? Removes the `Copy` bound from `IndexedSource::Item`. It also makes `LaneZip` fields private, validates lengths once in `LaneZip::new`, and removes the repeated assertion from its inline `len` method. This is a prerequisite only. The first production RowFn adopter is in #9345, so there is no meaningful RowFn performance comparison at this layer. ## What APIs are changed? Are there any user-facing changes? `LaneZip` must now be constructed with `LaneZip::new` instead of tuple syntax. The workspace has no direct field construction outside this module. Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
f8670a8 to
f108cdd
Compare
|
Here are the local arithmetic benchmark results from the final Rust 1.97.1 run. The comparison used a The machine was an AMD Ryzen 9 7950X running Linux. The build used rustc 1.97.1, LLVM 22.1.6, one CGU, fat LTO, and Negative changes are faster. The values are medians across the seven paired runs. The main results are:
A separate comparison covered the later naming and structural cleanup. All 24 RowFn matrix cases remained between 2.59% faster and 1.09% slower. RowFn arithmetic matrix: 24 cases
Existing arithmetic cases and controls: 28 cases
|
b2495de to
c1584a6
Compare
c1584a6 to
b722af5
Compare
b722af5 to
eea857d
Compare
0e8ab1d to
7693f90
Compare
1dd63b9 to
9be3db4
Compare
a517965 to
2d2af5d
Compare
2d2af5d to
dfd648d
Compare
425e336 to
adcff3b
Compare
Route primitive numeric kernels through RowFn while retaining Binary as the public scalar function identity. Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
adcff3b to
b7eb750
Compare
Rationale for this change
Makes primitive arithmetic the first production user of
RowFn.Binarykeeps its registered identity and existing scalar-function hooks.RowFnAPI #9129RowFnover Vortex arrays #9130What changes are included in this PR?
Checked add, subtract, and multiply reduce compact failure evidence outside their vector loops. Integer division stops at the first failure and writes directly into uninitialized output. Decimal arithmetic remains on its existing columnar path.
With Rust 1.97.1 and LLVM 22.1.6, optimized IR and assembly confirm that mixed-constant add, subtract, and multiply vectorize under the 16-CGU, no-LTO benchmark profile. The earlier 4.6–7.5x mixed-constant regressions were measured before the output-iterator fix in #9353 and no longer describe this branch.
What APIs are changed? Are there any user-facing changes?
There are no public API changes. Primitive arithmetic delegates execution to the private
NumericBinaryrow kernel.