-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
ARROW-9453: [Rust] Wasm32 compilation support #7767
Conversation
assert_eq!(ceil(10000000000, 10), 1000000000); | ||
assert_eq!(ceil(10, 10000000000), 1); | ||
assert_eq!(ceil(10000000000, 1000000000), 10); | ||
assert_eq!(ceil(10000000, 10), 1000000); |
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.
Why the changes here?
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 will double check these changes. I made them in response to a test that was failing; however, I found it suspect at the time as well.
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.
The numbers are 64-bit, which won't be supported in wasm32
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 think wasm32 supports i64 and f64 https://webassembly.github.io/spec/core/syntax/types.html
@rj-atw I would like to see us get wasm support but I think we need to add CI for this. Without CI all those |
Also, I assigned the JIRA to you and changed your permissions so you can self-assign in future |
@paddyhoran I love to add the need CI. Do we have any documentation around this projects CI (especially how to setup env locally)? |
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.
It will be good to add more details in the PR description, e.g., what have been disabled for wasm32 and what are the consequences etc.
@@ -24,3 +24,7 @@ members = [ | |||
"integration-testing", | |||
"benchmarks", | |||
] | |||
default-members= [ |
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.
Why add this? is this related to the change?
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.
Is this just so that wasm builds by default at the top level? If so, I'd rather not do this either. i.e. it's enough to just say that we can build the sub-crates on wasm instead of changing this global default.
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.
Yes. This was add as I did not try and port the Flight and Parquet submodules as I believe their core functionality uses file and sockets which don't have stable support in WASM yet.
I'll try out the individual submodule build, add details to readme and revert the Cargo.toml change.
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.
Made a couple of comments. Nice to see this opened!
#[cfg(all(any(target_arch = "x86", target_arch = "x86_64"), feature = "simd"))] | ||
fn simd_math_op<T, F>( | ||
#[cfg(all(any(target_arch = "x86", target_arch = "x86_64", target_arch="wasm32"), feature = "simd"))] | ||
pub fn simd_math_op<T, F>( |
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.
These don't need to be public, they are internally selected based on feature gates.
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. I made this modification to explicitly test that simd op call was not failing in WASM. Forgot to revert while pushing
pub mod csv; | ||
pub mod datatypes; | ||
pub mod error; | ||
#[cfg(feature = "flight")] | ||
#[cfg(all(feature = "flight",not(target_arch="wasm32")))] |
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.
Inconsistent spacing between macro features and selections. Please reorganize them consistently.
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.
Also please run cargo fmt and cargo clippy
paste = "0.1" | ||
|
||
[target.'cfg(not(target_arch="wasm32"))'.dependencies] | ||
parquet = { path = "../parquet", version = "1.0.0-SNAPSHOT" } |
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.
Don't not gate parquet if not wasm. The parquet should be also wasm compilable. Moreover, actual dependencies shouldn't be gated under the negated set, which makes it harder to maintain.
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.
Will look more into parquet library. I skipped many as it is primarily used to read from the file system...which I believe does not have stable support yet in WASM.
If I change to use a positive gate should I restrict to just x86 and x86_64; or are there other supported targets?
#[cfg(target_arch="wasm32")] | ||
pub fn main() { | ||
} |
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.
What is the point of not compiling the ported code? I don't see the benefit of porting to wasm by doing this.
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.
WASM is a library only. I believe this code is only useful when creating an executable.
I know this is a bad hack, but I am actually not really sure why this file was still pickup by rustc as I should be excluding in the package dependencies.
I'll take another look at why this is still being compile. However, I am open to suggestion/discussion on alternatives.
If you search for "rust" under the top level "ci" folder you will find most of the CI scripts. We can then ask @kszucs for a quick review of that part of the PR. |
@rj-atw you can start here https://github.com/apache/arrow/blob/master/docs/source/developers/docker.rst I assume you'll need to adjust the rust_build.sh script to accept either a target arch environment variable (preferable) or a CLI argument than add a new docker-compose entry (like debian-rust-wasm32) similar to debian-rust where you pass the wasm variable. Once that works with |
@rj-atw where you able to figure out CI? It looks like this also needs to be rebased. |
Hi @rj-atw, this PR has fallen behind quite a lot. Are you still interested in or able to work on this feature? Otherwise we could close the PR in the interim. |
@rj-atw I am adding wasm32 compilation to the CI, so that this can progress. Is this something that you are still interested on, or should we close this PR? |
I am still intersted.
Started new job, so diverted my attention. But hoping to close this out
during holiday break.
…On Mon, Dec 7, 2020, 10:10 PM Jorge Leitao ***@***.***> wrote:
@rj-atw <https://github.com/rj-atw> I am adding wasm32 compilation to the
CI, so that this can progress. Is this something that you are still
interested on, or should we close this PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7767 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOPXAG6UVNNQB37QW64C4KDSTW7NPANCNFSM4O2AJQEA>
.
|
@rj-atw -- FYI @jorgecarleitao has the appropriate CI support here: #8864 which you can probably pull into this PR |
This is a requirement fielded to merge #7767, and so I though about adding it to our CI. I am not sure whether this is exactly what we need to test #7767, and so I would like to request help from @paddyhoran and @rj-atw here. NOTE: this is built on top of #8821 . Only the last commit is relevant. Basically, this runs ``` rustup add target wasm32-unknown-unknown cd rust/arrow cargo build --target wasm32-unknown-unknown ``` Note that this does not actually run the tests yet. I think that that is #7767 's goal. Closes #8864 from jorgecarleitao/wasm32 Authored-by: Jorge C. Leitao <[email protected]> Signed-off-by: Andrew Lamb <[email protected]>
@rj-atw -- Given the imminent Arrow 3.0 release, I am trying to clean up older Rust PRs and see if the authors have plans to move them forward. Do you plan on working on this PR in the near future? If not, should we close this PR until there is time to make progress? Thanks again for your contributions so far. |
I'm closing this for now @alamb @rj-atw, we can pick it up later. |
This is a requirement fielded to merge apache#7767, and so I though about adding it to our CI. I am not sure whether this is exactly what we need to test apache#7767, and so I would like to request help from @paddyhoran and @rj-atw here. NOTE: this is built on top of apache#8821 . Only the last commit is relevant. Basically, this runs ``` rustup add target wasm32-unknown-unknown cd rust/arrow cargo build --target wasm32-unknown-unknown ``` Note that this does not actually run the tests yet. I think that that is apache#7767 's goal. Closes apache#8864 from jorgecarleitao/wasm32 Authored-by: Jorge C. Leitao <[email protected]> Signed-off-by: Andrew Lamb <[email protected]>
Adding compilation flag to allow rust library to compile against Wasm32 target