-
Notifications
You must be signed in to change notification settings - Fork 3.9k
ARROW-17836: [C++] Allow specifying alignment of buffers #14225
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
Conversation
|
|
|
|
e8091e8 to
cff0300
Compare
pitrou
left a comment
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.
Assuming we want this, the API additions seem reasonable.
(but allocations should already be 64-byte aligned: do you actually need more? if so, why?)
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.
Same question as for testing/random.h: is this useful?
8ba3697 to
4d45225
Compare
c398b3e to
bf873b1
Compare
|
Seems like the only CI issue is I see this issue on some other PRs and also I don't touch this test at all in my code, so I think this is fine. |
22d0d99 to
6a22194
Compare
|
Rebasing, the R errors are gone but the scanner test seems to be failing: Again, probably not me. I'd guess related to Weston's scanner refactor. |
|
@westonpace ^^ |
|
Also opened https://issues.apache.org/jira/browse/ARROW-17927 for a similar issue on scanner tests. |
333882c to
6a52954
Compare
6a52954 to
cb2b28d
Compare
cb2b28d to
e9b3ac0
Compare
westonpace
left a comment
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.
Sorry about the earlier test troubles. I think the API is fine. If we really wanted to avoid the extra arguments to buffer builder / etc. we could work around it with something like:
class ARROW_EXPORT EnforcedAlignmentMemoryPool : public MemoryPool {
public:
EnforcedAlignmentMemoryPool(int64_t default_alignment, MemoryPool* target)
: default_alignment_(default_alignment), target_(target) {}
Status Allocate(int64_t size, uint8_t** out) {
return target_->Allocate(size, default_alignment_, out);
}
virtual Status Allocate(int64_t size, int64_t alignment, uint8_t** out) {
if (alignment != default_alignment_) {
return Status::Invalid("Enforced alignment ", default_alignment_,
" but was asked for ", alignment);
}
return target_->Allocate(size, alignment, out);
}
// ...
That being said, I think I slightly prefer changing the buffer builders to take in an alignment argument as those are user facing and it makes things more clear to the user. I'm +0 on the changes to test utilities.
Could we add maybe one unit test to memory_test.cc just to provide a quick check in case someone wants to create a new memory pool implementation in the future.
pitrou
left a comment
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.
Thanks for the update!
Besides the minor comments I posted, I think we should add tests in two places at least:
- for MemoryPool in
arrow/memory_pool_test.cc - for BufferBuilder in
arrow/buffer_test.cc
7816209 to
134fca7
Compare
b1db9e3 to
3948cb2
Compare
|
@save-buffer I added some tests for the random array generator and it turns out that list arrays may not end up aligned due to |
|
@github-actions crossbow submit -g cpp |
|
Revision: 3948cb2 Submitted crossbow builds: ursacomputing/crossbow @ actions-0ee166c579 |
|
Thanks for adding those, yes I agree this PR is big enough for now. Adding support for Lists the issue is that the buffers passed in may not be aligned, right? This may be more convenient to do after we have a utility that will reallocate/copy to a specific alignment if needed (I think Sanjiban is working on something like that?) |
Yes, I already have that utility ready. I am waiting for this PR to get merged and I will then make a PR for ensuring alignment. |
No, it's just that random generation for lists calls |
|
Benchmark runs are scheduled for baseline = 63f013c and contender = 2078af7. 2078af7 is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
Lead-authored-by: Sasha Krassovsky <krassovskysasha@gmail.com> Co-authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
No description provided.