pub use std::simd::StdFloat; #93146
pub use std::simd::StdFloat; #93146
Conversation
For all other operators, we use wrapping logic where applicable. This is another case it applies. Per rust-lang#91237, we may wish to specify this as the natural behavior of `simd_{shl,shr}`.
This should perform a SIMD check for whether or not we can div/rem, so that we can panic several times faster!
This approaches reducing macro nesting in a slightly different way. Instead of just flattening details, make one macro apply another. This allows specifying all details up-front in the first macro invocation, making it easier to audit and refactor in the future.
Refactor ops.rs with wrapping shifts This approaches reducing macro nesting in a slightly different way. Instead of just flattening details, make one macro apply another. This allows specifying all details up-front in the first macro invocation, making it easier to audit and refactor in the future. This refactor also has some functional changes. Only one is a true behavior change, however: - The visible one is that SIMD shifts are now wrapping, not panicking on overflow - `core::simd` now has a lot more instances of `#[must_use]`, which merely lints - div/rem now perform a SIMD check but remain as before, which should improve performance but be invisible
While consulting with Simulacrum on how to make available the float
functions that currently require runtime support for `Simd<f32, N>` and
`Simd<f64, N>`, we realized breaking coherence with the classic approach
of lang items was, since `{core,std}::simd::Simd` is a `ty::Adt`, likely
to be quite a bit nasty. The project group has a long-term plan for how
to get around this kind of issue and move the associated functions into
libcore, but that will likely take time as well. Since all routes
forward are temporally costly, we probably will skip the lang item
approach entirely and go the "proper" route, but in the interests of
having something this year for people to play around with, this
extension trait was whipped up.
For now, while it involves a lot of fairly internal details most users
shouldn't have to care about, I went ahead and fully documented the
situation for any passerby to read on the trait, as the situation is
quite unusual and puzzling to begin with.
impl std::simd::StdFloat This introduces an extension trait to allow use of floating point methods that need runtime support. It is *excessively* documented because its mere existence is quite vexing, as the entire thing constitutes a leakage of implementation details into user observable space. Eventually the entire thing will ideally be folded into core and restructured to match the rest of the library, whatever that structure might look like at the time. This is preferred in lieu of the "lang item" path because any energy the lang items require (and it will be significant, by Simulacrum's estimation) is better spent on implementing our libmvec.
…nsic Use intrinsic for min/max
This significantly simplifies codegen and should improve mask perf. Co-authored-by: Jacob Lifshay <programmerjake@gmail.com>
The way the macro expands, it may sometimes infer "this is a uint, but doesn't impl Neg???" Also, I made the "wrong path for intrinsics" error. These fixes allow integration into libcore.
rustbot
added
the
T-compiler
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
workingjubilee
force-pushed
the
use-std-simd
branch
from
53a4c67
to
1a18a4b
Compare
Remove redundant "neither" in the documentation comment.
Co-authored-by: Alexander Ronald Altman <alexanderaltman@me.com>
fix documentation typo
Add Simd::cast Add core_simd/tests/cast.rs
Make available the remaining float intrinsics that require runtime support from a platform's libm, and thus cannot be included in a no-deps libcore, by exposing them through a sealed trait, `std::simd::StdFloat`. We might use the trait approach a bit more in the future, or maybe not. Ideally, this trait doesn't stick around, even if so. If we don't need to intermesh it with std, it can be used as a crate, but currently that is somewhat uncertain.
workingjubilee
force-pushed
the
use-std-simd
branch
from
1a18a4b
to
e96159e
Compare
|
Apologies if you had already started review, I pulled in the latest commits from portable-simd. I don't plan to move the sync point ahead again, it's just that we received so many requests for this |
|
Just to confirm: these changes are seeing upstream review, right? Typically the subtree part of a subtree bump doesn't need (detailed) review, since it's already been reviewed. The std changes here look OK to me from an integration perspective -- r=me after confirming that the other changes have been reviewed upstream (and you're not desiring another pass or specific examination of any of them) It may make sense to just glob re-export some part of std_simd rather than specifically exporting the StdFloat trait, but there's advantages to this approach to and it seems OK for now. |
|
'kayo! I will make a note of that in the future! And yes indeed, we are making sure we review each other's work here. I only really wanted to make sure the way I pushed things into |
|
📌 Commit e96159e has been approved by |
bors
added
S-waiting-on-bors
|
@bors rolllup=never (in case of perf impact) |
|
@bors rollup=never |
|
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@796bf14. Direct link to PR: <rust-lang/rust#93146> 💔 miri on windows: test-pass → test-fail (cc @RalfJung @eddyb @oli-obk).
|
Finished benchmarking commit (796bf14): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Syncs portable-simd up to commit rust-lang/portable-simd@03f6fbb,
Diff: rust-lang/portable-simd@533f0fc...03f6fbb
This sync requires a little bit more legwork because it also introduces a trait into
std::simd, so that it is no longer simply a reexport ofcore::simd. Out of simple-minded consistency and to allow more options, I replicated the pattern for the waycore::simdis integrated in the first place, however this is not necessary if it doesn't acquire any interdependencies insidestd: it could be a simple crate reexport. I just don't know yet if that will happen or not.To summarize other misc changes:
Simdintegers usually do!)#[must_use]is spread around generouslyMask::{from,to}_arrayinternally to be fasterSimd::cast::<U>function (equivalent tosimd.to_array().map(|lane| lane as U))