-
Notifications
You must be signed in to change notification settings - Fork 145
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
RFC: rewrite based on min_const_generics for 2.0 #240
Comments
I like this plan. |
I looked into some possible I was motivated by a few comments here, which described a large branch prediction penalty for spilled Some data here suggests large performance improvements when using a (32-bit) It occurred to me that, with the I experimented with code which reduced all branching in Unless you're willing to use inline assembly behind a feature flag, this idea is probably at a dead end. You could experiment with bit-masking as a replacement for |
Remove `min_const_generics` feature Depends on rust-lang/rust#79135. If #240 is already under development and will be available before the 1.50 release, then feel free to close this PR. Otherwise, the feature removal will benefit upstream projects in the meanwhile.
its been about a year now - any movement here? min_const_generics is fully stable |
@TheButlah Nope, after the burst of inspiration that led to writing up this plan I ended up spending exactly zero additional time on it. Time since is irrelevant. I still like this plan but I can’t say when or if I’ll work on it. Anyone should feel free to take over. |
Wait, that’s not quite true. It looks like I did write some proof-of-concept code the same day as this issue, and got bored at drawing the rest of the owl. It’s not even in a git repository. Here it in case anyone wants to take a look |
There is now a serious proposal and plan to stabilize
#![feature(min_const_generics)]
in Rust 1.50: rust-lang/rust#79135. Using it here and removing theArray
trait would a welcome simplification but obviously a breaking API change, so it would need to be part of a version 2.0 of the crate.I’m wondering whether it would make sense to try a complete rewrite of
smallvec
instead of adapting the existing code. Some ideas:The current
capacity
field has a misleading name and non-obvious meaning, it can represent either the capacity or the length of the vector. I feel this makes the code harder to understand and keep correct than necessary. Instead we could store a length in the0..isize::MAX
range, and pack a tag in the remaining bit.The dual representation with conditional compilation can be skipped/removed entirely, as
union
s withManuallyDrop<T>
fields withT: !Copy
are now stable: stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' rust-lang/rust#77547The "core" of the crate can be rather small (and in a separate module and file), with everything else mostly copied from
vec.rs
andraw_vec.rs
from the standard libraryCopying from the standard library again gets us more recent improvements, such as making some code less generic to reduce monomorphization bloat.
This would be a good time to look at
unsafe
code2.0 can be an opportunity to remove some APIs. For example,
IntoIterator for SmallVec
implies an expensive move. We could omit it and document to usedrain
instead.I’d consider not necessarily including everything in #183, as specialization and custom allocators are likely not gonna be stable before or soon after
min_const_generics
is. Adding those might not require breaking API changes, though?I’ve started playing with this a little. Here is the core data structure:
The
union
and tagged integer wrangling as well as heap (re/de)allocations could be in a private module, with the rest of the functionality (push
,drain
,try_reserve
, …) built on top of an abstraction such as:The text was updated successfully, but these errors were encountered: