Extend aggregation benchmarks #5096
Conversation
- Add benchmarks for float64 and integer types - Measure throughput - Increase batch size so that the final reduction step has less of an impact
| criterion::black_box(min_string(arr_a).unwrap()); | ||
| fn primitive_benchmark<T: ArrowNumericType>(c: &mut Criterion, name: &str) | ||
| where | ||
| Standard: Distribution<T::Native>, |
There was a problem hiding this comment.
I doubt it matters for this benchmark, but it is perhaps worth noting that the standard distribution for floats is only between 0 and 1. I don't think this would make a difference to timings, but FYI
There was a problem hiding this comment.
Good to know, and agree it shouldn't affect the timings. The bound is required by bench_utils::create_primitive_array.
| .throughput(Throughput::Bytes( | ||
| (std::mem::size_of::<T::Native>() * BATCH_SIZE) as u64, | ||
| )) | ||
| .bench_function("sum nonnull", |b| b.iter(|| sum(&nonnull_array))) |
There was a problem hiding this comment.
I'm surprised this isn't overflowing, unless sum always wraps?
There was a problem hiding this comment.
It is indeed always wrapping, scalar version goes through ArrowNativeTypeOp::add_wrapping and I guess the simd version wraps by default. There seems to be a separate sum_checked kernels, I'm not sure yet whether that could be vectorized.
Which issue does this PR close?
Preparation for #5032.
Rationale for this change
To better evaluate a autovectorized version of the aggregation kernels we should benchmark more data types and not only f32.
I also noticed that because of the relatively small batch size, the final reduction step of multi-lane aggregations has a large impact on the total timings. The PR increases the batch size to 64k, which matches the batch size used in the arithmetic and comparison benchmarks.
What changes are included in this PR?
Are there any user-facing changes?
no