chore[array]: move over filtering to {reduce/execute}_parent#6312
chore[array]: move over filtering to {reduce/execute}_parent#6312joseph-isaacs merged 8 commits intodevelopfrom
{reduce/execute}_parent#6312Conversation
{reduce/execute}_parent
CodSpeed Performance ReportMerging this PR will improve performance by 50.07%Comparing Summary
Performance Changes
Footnotes
|
Benchmarks: Statistical and Population GeneticsSummary
Detailed Results Table
|
Benchmarks: TPC-H SF=1 on S3Summary
Detailed Results Table
|
Benchmarks: TPC-DS SF=1 on NVMESummary
Detailed Results Table
|
Benchmarks: FineWeb S3Summary
Detailed Results Table
|
Benchmarks: FineWeb NVMeSummary
Detailed Results Table
|
Benchmarks: TPC-H SF=10 on S3Summary
Detailed Results Table
|
Benchmarks: Clickbench on NVMESummary
Detailed Results Table
|
Benchmarks: TPC-H SF=10 on NVMESummary
Detailed Results Table
|
Benchmarks: TPC-H SF=1 on NVMESummary
Detailed Results Table
|
Benchmarks: Random AccessSummary
|
Benchmarks: CompressionSummary
Detailed Results Table
|
8252b66 to
4b34d59
Compare
77e00c9 to
0e6a0a2
Compare
|
I think we should keep the precondition until we know those masks are opt away |
| }) | ||
| /// The threshold over which it is faster to fully unpack the entire [`BitPackedArray`] and then | ||
| /// filter the result than to unpack only specific bitpacked values into the output buffer. | ||
| pub const fn unpack_then_filter_threshold(ptype: PType) -> f64 { |
There was a problem hiding this comment.
Why pub? Pub(crate) at most?
|
For the super-common rules/kernels against builtin arrays like slice and filter, I wonder whether it does make sense to make it super obvious for plugin authors that they should think about implementing these. e.g. |
|
I think we could have a Optimized Array trait the forces impls for slice and filter. |
|
But you still need to attach the rules |
No description provided.