Use the trifecta div algorithm for 128-bit div on wasm #685
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit updates the `#[cfg]` annotations used to select the implementation of 128-bit division in compiler-builtins on wasm targets. This is done with relation to https://github.com/WebAssembly/128-bit-arithmetic where performance of 128-bit operations is being investigated on WebAssembly. While I don't know much about the particulars of the two algorithms involved here the comments indicate that the "trifecta" variant is preferred if possible but it's not selected on 32-bit architectures. This rationale isn't as applicable to WebAssembly targets because despite the 32-bit pointer width there are often wider-than-pointer operations available as it's typically run on 64-bit machines. Locally in testing a benchmark that performs division with a Rust-based bignum libraries whent from 350% slower-than-native to 220% slower-than-native with this change, a nice increase in speed. While this was tested with Wasmtime other runtimes are likely to see an improvement as well.
|
Makes sense, thanks! |
|
Once #684 merges you can send a PR to rust-lang/rust updating to v0.1.125 |
|
Happy to do so, and thanks! |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Sep 5, 2024
This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Sep 11, 2024
…ins, r=tgross35 Update compiler-builtins to 0.1.125 This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685 Fixes: rust-lang#129823
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 11, 2024
…s, r=<try> Update compiler-builtins to 0.1.125 This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685 try-job: aarch64-apple try-job: aarch64-gnu try-job: armhf-gnu try-job: test-various
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 12, 2024
…ins, r=tgross35 Update compiler-builtins to 0.1.125 This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 12, 2024
…s, r=tgross35 Update compiler-builtins to 0.1.125 This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Sep 14, 2024
…ss35 Update compiler-builtins to 0.1.125 This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685
lnicola
pushed a commit
to lnicola/rust-analyzer
that referenced
this pull request
Sep 25, 2024
…ss35 Update compiler-builtins to 0.1.125 This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685
shrirambalaji
pushed a commit
to shrirambalaji/rust
that referenced
this pull request
Oct 6, 2024
This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit updates the
#[cfg]annotations used to select the implementation of 128-bit division in compiler-builtins on wasm targets. This is done with relation tohttps://github.com/WebAssembly/128-bit-arithmetic where performance of 128-bit operations is being investigated on WebAssembly. While I don't know much about the particulars of the two algorithms involved here the comments indicate that the "trifecta" variant is preferred if possible but it's not selected on 32-bit architectures. This rationale isn't as applicable to WebAssembly targets because despite the 32-bit pointer width there are often wider-than-pointer operations available as it's typically run on 64-bit machines.
Locally in testing a benchmark that performs division with a Rust-based bignum libraries whent from 350% slower-than-native to 220% slower-than-native with this change, a nice increase in speed. While this was tested with Wasmtime other runtimes are likely to see an improvement as well.