feat: teach ALPArray to store validity only in the encoded array & other minor changes#2053
Closed
danking wants to merge 15 commits into
Closed
feat: teach ALPArray to store validity only in the encoded array & other minor changes#2053danking wants to merge 15 commits into
danking wants to merge 15 commits into
Conversation
github-actions
Bot
removed
the
action/benchmark
Contributor
Author
|
previously: #1951 |
Contributor
Benchmarks: random_accessTable of Results
|
Contributor
Benchmarks: datafusionTable of Results
|
Contributor
Benchmarks: ClickbenchTable of Results
|
a10y
reviewed
Jan 22, 2025
| let (encoded, exceptional_positions) = T::chunked_encode(values.as_slice::<T>(), exponents); | ||
|
|
||
| let encoded_array = PrimitiveArray::new(encoded, values.validity()).into_array(); | ||
| let exceptional_positions = match values.logical_validity() { |
Contributor
There was a problem hiding this comment.
could we add like 1-2 comments in this section just to make it clear what is going on
Contributor
Author
There was a problem hiding this comment.
LMK what you think, I added a comment above this line.
danking
force-pushed
the
dk/alp-validity-in-encoded-only
branch
from
b5b44e0 to
ca17b75
Compare
github-actions
Bot
removed
the
action/benchmark
This comment was marked as outdated.
This comment was marked as outdated.
Contributor
Benchmarks: TPC-HTable of Results
|
github-actions
Bot
removed
the
action/benchmark
Contributor
|
@danking you should make sure you run with RUSTFLAGS='-C target-cpu=native' we had to axe it from our repo cargo config since it messed up cross compilation |
This comment was marked as outdated.
This comment was marked as outdated.
Contributor
Benchmarks: compressTable of Results
|
The patches are now always non-nullable. This required PrimitiveArray::patch to gracefully handle non-nullable patches when the array is nullable. I modified the benchmarks to include patch manipulation time, but notice that the test data has no patches. The benchmarks measure the overhead of `is_valid`. If we had test data where the invalid positions contained exceptional values, I would expect a modest improvement in both decompression and compression time.
danking
force-pushed
the
dk/alp-validity-in-encoded-only
branch
from
0351f19 to
e5709ef
Compare
danking
changed the title
danking
changed the title
github-actions
Bot
removed
the
action/benchmark
a10y
reviewed
Jan 31, 2025
Comment on lines
+167
to
+168
| if let Some(fill_value) = | ||
| Self::first_non_patched_encoded_value(&encoded, &patch_indices) |
Contributor
There was a problem hiding this comment.
just use unwrap_or_default() to fallback to zero
Contributor
There was a problem hiding this comment.
the original code also does this: https://github.com/cwida/ALP/blob/main/include/alp/encoder.hpp#L379-L385
a10y
reviewed
Jan 31, 2025
Comment on lines
-214
to
-220
| encoded_output.extend(chunk.iter().map(|v| { | ||
| let encoded = unsafe { T::encode_single_unchecked(*v, exp) }; | ||
| let decoded = T::decode_single(encoded, exp); | ||
| let neq = (decoded != *v) as usize; | ||
| chunk_patch_count += neq; | ||
| encoded | ||
| })); |
Contributor
There was a problem hiding this comment.
This loop structure is actually pretty important for performance.
You can refer to the original code where this is actually separated out into two loops:
Loop 1: calculate and materialize encoded + decoded vectors
Loop 2: find the exceptions by looping through the zipped vectors to find mismatches
https://github.com/cwida/ALP/blob/main/include/alp/encoder.hpp#L338-L346
https://github.com/cwida/ALP/blob/main/include/alp/encoder.hpp#L370-L376
I'm not sure i personally find the new version on the right more readable, but I want to make sure we keep a similar structure that the branch predictor likes
danking
force-pushed
the
dk/alp-validity-in-encoded-only
branch
from
e0e2528 to
c2580f0
Compare
Contributor
Author
|
Moved here: #2216 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The original change of this PR trims invalid values from the patches and makes the patches validity either AllValid (for nullable arrays) or NonNullable.
Benchmarks on latest commit:
parameter is: (number of elements, fraction patched, fraction valid).
Any ratio greater than 1.1 or less than 0.9 has a
***Benchmarks before reverting to develop's chunking code
Details
[1] Seems like this PR is about the same except for compressing really large f64 arrays. The PR that introduced chunking, #924, reported substantially larger reductions (~5ms of 29ms) in time than this increase of ~1ms (of 17ms).