-
Notifications
You must be signed in to change notification settings - Fork 807
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Datum based comparison kernels (#4596) #4701
Changes from all commits
8cce942
e309227
c78212c
ceee661
c41d948
0653162
dec1970
01dc052
023a3ef
7a858a8
1a934d6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -33,10 +33,9 @@ use arrow_array::builder::{ | |
ArrayBuilder, BooleanBuilder, Int32Builder, Int64Builder, Int8Builder, ListBuilder, | ||
MapBuilder, StringBuilder, UInt32Builder, | ||
}; | ||
use arrow_array::cast::downcast_array; | ||
use arrow_array::RecordBatch; | ||
use arrow_array::{RecordBatch, Scalar}; | ||
use arrow_data::ArrayData; | ||
use arrow_ord::comparison::eq_scalar; | ||
use arrow_ord::cmp::eq; | ||
use arrow_schema::{DataType, Field, Fields, Schema, SchemaRef, UnionFields, UnionMode}; | ||
use arrow_select::filter::filter_record_batch; | ||
use once_cell::sync::Lazy; | ||
|
@@ -425,13 +424,16 @@ impl SqlInfoData { | |
&self, | ||
info: impl IntoIterator<Item = u32>, | ||
) -> Result<RecordBatch> { | ||
let arr: UInt32Array = downcast_array(self.batch.column(0).as_ref()); | ||
let arr = self.batch.column(0); | ||
let type_filter = info | ||
.into_iter() | ||
.map(|tt| eq_scalar(&arr, tt)) | ||
.map(|tt| { | ||
let s = UInt32Array::from(vec![tt]); | ||
eq(arr, &Scalar::new(&s)) | ||
Comment on lines
+431
to
+432
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similarly, I think this would read better like
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Proposal in #4704 |
||
}) | ||
.collect::<std::result::Result<Vec<_>, _>>()? | ||
.into_iter() | ||
// We know the arrays are of same length as they are produced fromn the same root array | ||
// We know the arrays are of same length as they are produced from the same root array | ||
.reduce(|filter, arr| or(&filter, &arr).unwrap()); | ||
if let Some(filter) = type_filter { | ||
Ok(filter_record_batch(&self.batch, &filter)?) | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -44,10 +44,3 @@ half = { version = "2.1", default-features = false, features = ["num-traits"] } | |
|
||
[dev-dependencies] | ||
rand = { version = "0.8", default-features = false, features = ["std", "std_rng"] } | ||
|
||
[package.metadata.docs.rs] | ||
features = ["dyn_cmp_dict"] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this an API change? (if someone was using arrow-ord directly) I see that |
||
|
||
[features] | ||
dyn_cmp_dict = [] | ||
simd = ["arrow-array/simd"] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The SIMD variants added a non-trivial amount of code complexity, and behaved differently. I opted to simply remove them, we can always add back some sort of SIMD specialization for primitives in future should users feel strongly There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For other kernels as I recall we found properly written rust code would be vectorized by llvm more effectively than our hand rolled simd kernels. Do you think that is still the case? cc @jhorstmann There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is empirically not the case here, LLVM is really bad at optimising horizontal operations such as creating a packed bitmask from a comparison. The LLVM generated kernels are ~2x slower There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. correct, though I feel like llvm has gotten a little better at this. on the other hand, the simd kernels also did not generate "perfect" code due to combining multiple masks into a single u64 (except for u8 comparisons which have 64 lanes). I think the tradeoff against improved compile time is ok, and longer term this allows more code cleanups. The decimal types for example already had a quite hacky support for simd. The last simd usages then would be the aggregation kernels. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I user I find this construction somewhat awkward to create a simple scalar
What would you think about creating convenience functions that would let this code be like:
(doesn't have to be part of this PR, I can add it as a follow on ticket/PR)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll have a think about what we can do here