impl std::simd::StdFloat #219
Conversation
workingjubilee
force-pushed
the
std-float
branch
from
6c7d0b7
to
dd40432
Compare
workingjubilee
force-pushed
the
std-float
branch
from
dd40432
to
3174cb2
Compare
| @@ -2,5 +2,6 @@ | |||
|
|
|||
| members = [ | |||
| "crates/core_simd", | |||
| "crates/std_float", | |||
There was a problem hiding this comment.
Should this crate maybe be called std_simd? It only has the extra float stuff for now, but it could end up with something unexpected.
There was a problem hiding this comment.
It's not necessarily obvious we would want to keep anything else we include in std in the same crate (since, notionally, this one ought to be Doomed) and we'd likely have to adjust the paths for inclusion anyways (to use the more complicated scheme). It's fine to rename it if something does come up.
| @@ -0,0 +1,165 @@ | |||
| #![cfg_attr(feature = "as_crate", no_std)] // We are std! | |||
There was a problem hiding this comment.
Why is this different than the lib.rs/mod.rs shenanigans in core_simd?
There was a problem hiding this comment.
Since it's just a single file we can just name it easily, and it doesn't cause any "dancing".
But when it's not "actually a crate", it's not allowed to set #![no_std]. I could probably adjust things more to be less complicated in this case (truly build as a crate and just reimport from std?) but I followed the same model as with core_simd so as to minimize any possible dependency issues in the Rust build system, as I would rather explore that as cleanup afterwards. I guess the question here is whether this will ever depend on something else inside std. If so: yes, we definitely need it to be included this way. If not, then it can just be its own entire thing.
|
I think we'll probably revisit this once we figure out what we're doing with traits at a larger scale (this may end up getting renamed to |
|
Hm. |
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.
workingjubilee
force-pushed
the
std-float
branch
from
aed46cb
to
af26e3b
Compare
|
Renamed it in anticipation of that possibility, to minimize churn for users. Unresolved questions:
|
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 not-insignificant, by Simulacrum's estimation) is better spent on implementing our libmvec.
I have already tested a sync of this branch into std and it works fine.
For further (and purely optional) reading on "why this", see:
SimdF32::sinand similar to work incore#109stdtocorerust#63455