Skip to content
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

Brainstorm official support for arm32v7 hardware architecture #6681

Open
drauschenbach opened this issue Nov 4, 2024 · 1 comment
Open
Labels
question Further information is requested

Comments

@drauschenbach
Copy link

This discussion aims to outline what would be required to add comprehensive support for the arm32v7 hardware architecture. Because it was in the top 3 best-selling computers of all time, and edge hardware is likely to remain in service for quite some time, and because edge is a particularly strong use case for Arrow.

And secondarily, consider how that might also benefit independent efforts to support WASM32.

Here are some of my own ideas:

  1. Perform tests and clippy static checks for both amd64 and armhf. amd64 must pass, armhf can fail until official support is completed.
  2. Tests that are specifically 64-bit in nature should not be attempted on 32-bit platforms (use #[cfg(target_pointer_width = "64")] around the test function). The POC at Don't attempt to run 64-bit tests on 32-bit platforms #6678 outlines most of these.
  3. Scrutinize test coverage for DecimalType, Decimal128Type and Decimal256Type which do not work on armhf.
  4. Scrutinize test coverage for Time64MicrosecondType and Time64NanosecondType, which do not work on armhf.
  5. Consider adding a badge to the README outlining current hardware platform support.
@tustvold
Copy link
Contributor

tustvold commented Nov 5, 2024

I think there needs to be a proper assessment of APIs that currently use usize and would need to switch to u64, e.g. null counts, ArrowNativeType, etc... This would be a fairly disruptive and involved breaking change and so would require getting a group together to properly action this.

There are also a lot of APIs that assume performant u64, e.g. bitmap processing, I'm not sure if these would need to be changed.

Unfortunately I do not have the capacity to help drive this and am unlikely to for the foreseeable future

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants