aarch64: Revert "Use CASP instead of LDXP/STXP for store/RMW if available" on Apple hardware #89
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
taiki-e
added
the
O-arm
…able" on Apple hardware As of Apple M1/M1 Pro, on Apple hardware, CAS loop-based RMW is much slower than LL/SC loop-based RMW. So, revert 93e6ec5 on Apple hardware for now. ``` Benchmarking bench_portable_atomic_arch/u128_concurrent_swap: Warming up for 3.0000 s Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 7.9s, enable flat sampling, or reduce sample count to 50. Benchmarking bench_portable_atomic_arch/u128_concurrent_swap: Collecting 100 bench_portable_atomic_arch/u128_concurrent_swap time: [1.4365 ms 1.5230 ms 1.5948 ms] change: [+378.49% +402.44% +424.27%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 8 (8.00%) low severe 4 (4.00%) low mild Benchmarking bench_portable_atomic_arch/u128_concurrent_store_swap: Warming u Benchmarking bench_portable_atomic_arch/u128_concurrent_store_swap: Collectin bench_portable_atomic_arch/u128_concurrent_store_swap time: [286.21 µs 292.15 µs 296.65 µs] change: [+96.504% +102.53% +108.63%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 6 (6.00%) low severe 2 (2.00%) low mild 1 (1.00%) high mild 2 (2.00%) high severe Benchmarking bench_portable_atomic_arch/u128_concurrent_fetch_add: Warming up for 3.0000 s Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 8.8s, enable flat sampling, or reduce sample count to 50. Benchmarking bench_portable_atomic_arch/u128_concurrent_fetch_add: Collecting bench_portable_atomic_arch/u128_concurrent_fetch_add time: [1.6351 ms 1.6787 ms 1.7170 ms] change: [+279.29% +294.80% +309.89%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 8 (8.00%) low severe 4 (4.00%) low mild 1 (1.00%) high mild ```
teohhanhui
reviewed
Oct 22, 2023
|
|
||
| // As of Apple M1/M1 Pro, on Apple hardware, CAS loop-based RMW is much slower than LL/SC | ||
| // loop-based RMW: https://github.com/taiki-e/portable-atomic/pull/89 | ||
| if is_macos || target_os == "ios" || target_os == "tvos" || target_os == "watchos" { |
There was a problem hiding this comment.
There was a problem hiding this comment.
Is there a way to know that the code is being compiled against Asahi Linux at build time?
Otherwise, it would be reasonable to set --cfg portable_atomic_ll_sc_rmw on the user's side.
There was a problem hiding this comment.
There is an option to revert the whole 93e6ec5, but we want to keep the same codegen as LLVM if possible (LLVM uses CASP regardless of whether it is Apple hardware, though), and we also need to make sure that it does not lose performance on hardware that CASP is fast.
There was a problem hiding this comment.
Is there a way to know that the code is being compiled against Asahi Linux at build time?
I can think of is:
- target_vendor. If custom targets are used.
-C target-cpu=apple-*. If the user uses it.
Both cases can be detected at build time, but I would like to know which one Asahi Linux users actually use.
There was a problem hiding this comment.
I've implemented the latter approach in 5c3a43b.
$ RUSTFLAGS='-C target-cpu=apple-m1' cargo build -vv --target aarch64-unknown-linux-gnu | grep portable_atomic_ll_sc_rmw
[portable-atomic 1.4.3] cargo:rustc-cfg=portable_atomic_ll_sc_rmw(build) EDIT: Published in 1.5.0.
There was a problem hiding this comment.
@teohhanhui Was the above approach sufficient for you? Or was it not?
There was a problem hiding this comment.
To be clear:
- Those specified in .cargo/config (or .cargo/config.toml) are also taken into account.
- With the builtin aarch64-unknown-linux-{gnu,musl} target, if you specify neither target-cpu nor target-feature, the default one (LL/SC) will be used and you should get good performance on apple hardwere.
taiki-e
added a commit
that referenced
this pull request
Oct 23, 2023
taiki-e
added
O-aarch64
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.
As of Apple M1/M1 Pro, on Apple hardware, CAS loop-based RMW is much slower than LL/SC loop-based RMW.
So, revert 93e6ec5 (#70) on Apple hardware for now.