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

ARROW-9453: [Rust] Wasm32 compilation support #7767

Closed
wants to merge 1 commit into from
Closed

ARROW-9453: [Rust] Wasm32 compilation support #7767

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Jul 15, 2020

Adding compilation flag to allow rust library to compile against Wasm32 target

@github-actions
Copy link

assert_eq!(ceil(10000000000, 10), 1000000000);
assert_eq!(ceil(10, 10000000000), 1);
assert_eq!(ceil(10000000000, 1000000000), 10);
assert_eq!(ceil(10000000, 10), 1000000);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the changes here?

Copy link
Author

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.

Copy link
Contributor

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

Copy link
Contributor

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

@paddyhoran
Copy link
Contributor

@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 cfg attributes are destined to go stale...

@paddyhoran
Copy link
Contributor

Also, I assigned the JIRA to you and changed your permissions so you can self-assign in future

@ghost
Copy link
Author

ghost commented Jul 15, 2020

@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 cfg attributes are destined to go stale...

@paddyhoran I love to add the need CI. Do we have any documentation around this projects CI (especially how to setup env locally)?

Copy link
Member

@sunchao sunchao left a 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= [
Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Author

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.

Copy link
Contributor

@vertexclique vertexclique left a 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>(
Copy link
Contributor

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.

Copy link
Author

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")))]
Copy link
Contributor

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.

Copy link
Contributor

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" }
Copy link
Contributor

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.

Copy link
Author

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?

Comment on lines +38 to +40
#[cfg(target_arch="wasm32")]
pub fn main() {
}
Copy link
Contributor

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.

Copy link
Author

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.

@paddyhoran
Copy link
Contributor

paddyhoran commented Jul 15, 2020

@paddyhoran I love to add the need CI. Do we have any documentation around this projects CI (especially how to setup env locally)?

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.

@kszucs
Copy link
Member

kszucs commented Jul 15, 2020

@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 archery docker run debian-rust-wasm32 you can add a matrix entry to execute debian-rust-wasm32 in the rust github actions configuration.

@emkornfield
Copy link
Contributor

@rj-atw where you able to figure out CI? It looks like this also needs to be rebased.

@nevi-me nevi-me added the needs-rebase A PR that needs to be rebased by the author label Nov 7, 2020
@nevi-me
Copy link
Contributor

nevi-me commented Nov 21, 2020

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.

@jorgecarleitao
Copy link
Member

@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?

@ghost
Copy link
Author

ghost commented Dec 8, 2020 via email

@alamb
Copy link
Contributor

alamb commented Dec 13, 2020

@rj-atw -- FYI @jorgecarleitao has the appropriate CI support here: #8864 which you can probably pull into this PR

alamb pushed a commit that referenced this pull request Dec 18, 2020
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]>
@alamb
Copy link
Contributor

alamb commented Jan 13, 2021

@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.

@nevi-me
Copy link
Contributor

nevi-me commented Jan 13, 2021

I'm closing this for now @alamb @rj-atw, we can pick it up later.

@nevi-me nevi-me closed this Jan 13, 2021
GeorgeAp pushed a commit to sirensolutions/arrow that referenced this pull request Jun 7, 2021
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Rust - DataFusion Component: Rust needs-rebase A PR that needs to be rebased by the author
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants