westonpace commented on PR #35565: URL: https://github.com/apache/arrow/pull/35565#issuecomment-1553280927
> But a misalignment can be reproduced https://github.com/apache/arrow/issues/32276, right? Yes, I can reproduce misaligned buffers. I cannot find a way to generate invalid behavior as a result of misaligned buffers (e.g. a crash or incorrect results). > Do we know that no other supported platform would have a problem with misalignment? Not really. It's undefined behavior. However, in practice, we usually get away with it. > Perhaps it's worth adding test-cases for tolerance to misalignment, even if they could only generate warnings? Yes, it would be valuable to add tests cases running on unaligned buffers. I think that is separate from this PR. > "A" makes compute kernel performance more noisy and unpredictable. IMO, that alone could be a reason to do our best to feed aligned data to compute kernels even with the potential alloc and copy before the kernel runs. Yes, I think we all agree that "ideally input should be aligned". I think the only point of contention is how to handle the case where it isn't given that we know, for the indeterminate future, such cases will be generated by flight. > "B" is a sign that relying on unaligned memory access makes us much more exposed to CPU bugs. In trusting modern CPUs unaligned-memory access machinery, we expose ourselves to risk. That machinery is even less trustworthy on SIMD instruction sets. I understand the point. This basically boils down to "Should we allow the user to get away with bad things because they normally work? Or should we insert a performance penalty even though it probably isn't necessary just to play it safe? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
