Noratrieb/blog
1
0
Fork 0
mirror of https://github.com/Noratrieb/blog.git synced 2026-01-14 12:35:00 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

improve last section

Browse source
This commit is contained in:
nora 2022-07-23 14:28:13 +02:00
parent 379f1b93cb
commit 9375a64eeb
1 changed files with 8 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

17
content/posts/box-is-a-unique-type.md
View file

@ -201,7 +201,7 @@ and I prefer the mental model of "reference that manages its own lifetime", whic
# noalias, noslow # noalias, noslow
There is one clear potential benefit from this box behaviour. ✨Optimizations✨. `noalias` doesn't exist for fun, it's something There is one clear potential benefit from this box behaviour: ✨Optimizations✨. `noalias` doesn't exist for fun, it's something
that can bring clear performance wins (for `noalias` on `&mut T`, those were measureable). So the only question remains: that can bring clear performance wins (for `noalias` on `&mut T`, those were measureable). So the only question remains:
**How much performance does `noalias` on `Box<T>` give us now, and how many potential performance improvements could we get in the **How much performance does `noalias` on `Box<T>` give us now, and how many potential performance improvements could we get in the
future?** For the latter, there is no simple answer. For the former, there is. `rustc` has [_no_ performance improvements](https://github.com/rust-lang/rust/pull/99527) future?** For the latter, there is no simple answer. For the former, there is. `rustc` has [_no_ performance improvements](https://github.com/rust-lang/rust/pull/99527)
@ -215,18 +215,17 @@ provide an aliasable version of `Box<T>`, which is used by the self-referential
# a way forward # a way forward
Based on all of this, I do have a solution that, in opinion, will fix all of this, even potential performance regressions with Based on all of this, I do have a few solutions. First of all, I think that even if there might be some small performance regressions in ecosystem crates,
box. First of all, I think that even if there are some performance regressions in ecosystem crates, the overall tradeoff goes the overall tradeoff goes against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
remove all uniqueness from `Box<T>`, and treat it just like a `*const T` for the purposes of aliasing. This will make it more remove all uniqueness from `Box<T>`, and treat it just like a `*const T` for the purposes of aliasing. This will make it more
predictable for unsafe code, and comes at none or only a minor performance cost. predictable for unsafe code, and comes at none or only a minor performance cost.
But this performance cost may be real, and especially the future optimization value can't be certain. I do think that there But this performance cost may be real, and especially the future optimization value can't be certain. The current uniqueness guarantees of box
should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be to use a are very strong, and still giving code an option to obtain these seems useful. One possibility would be for code to use a
`&'static mut T` that is unleaked for drop, but the semantics of this are still [unclear](https://github.com/rust-lang/unsafe-code-guidelines/issues/316). `&'static mut T` that is unleaked for drop, but the semantics of this are still [unclear](https://github.com/rust-lang/unsafe-code-guidelines/issues/316).
If that is not possible, maybe exposing `std::ptr::Unique` (with it getting boxes aliasing semantics) could be desirable. If that is not possible, exposing `std::ptr::Unique` (with it getting boxes aliasing semantics) could be desirable. For this, all existing usages of `Unique`
For this, all existing usages of `Unique` inside the standard library would have to be removed though. inside the standard library would have to be removed.
I guess what I am wishing for are some good and flexible raw pointer types. That's still in the stars... I guess what I am wishing for are some good and flexible raw pointer types. But that's still in the stars...
For more information about this topic, see https://github.com/rust-lang/unsafe-code-guidelines/issues/326 For more information about this topic, see https://github.com/rust-lang/unsafe-code-guidelines/issues/326