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

deploy: 9375a64eeb

Browse source
This commit is contained in:
Nilstrieb 2022-07-23 12:28:31 +00:00
parent f7ea5c3dbc
commit 3a526b579c
5 changed files with 40 additions and 45 deletions
Download patch file Download diff file Expand all files Collapse all files

17
index.xml
View file

@ -142,7 +142,7 @@ be said that <code>Box<T></code> <em>is</em> a very sp
justify all the box magic and its unique behaviour. But in my opinion, this is not a useful mental model regarding unsafe code,
and I prefer the mental model of “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
<h1 id="noalias-noslow">noalias, noslow</h1>
<p>There is one clear potential benefit from this box behaviour. ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’s something
<p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’s something
that can bring clear performance wins (for <code>noalias</code> on <code>&mut T</code>, those were measureable). So the only question remains:
<strong>How much performance does <code>noalias</code> on <code>Box<T></code> give us now, and how many potential performance improvements could we get in the
future?</strong> For the latter, there is no simple answer. For the former, there is. <code>rustc</code> has <a href="https://github.com/rust-lang/rust/pull/99527"><em>no</em> performance improvements</a>
@ -152,15 +152,14 @@ grateful if anyone wanted to pick that up and report the results.</p>
<p>There are also crates on <a href="https://crates.io/">crates.io</a> like <a href="https://crates.io/crates/aliasable">aliasable</a> that already
provide an aliasable version of <code>Box<T></code>, which is used by the self-referential type helper crate <a href="https://crates.io/crates/ouroboros">ouroboros</a>.</p>
<h1 id="a-way-forward">a way forward</h1>
<p>Based on all of this, I do have a solution that, in opinion, will fix all of this, even potential performance regressions with
box. First of all, I think that even if there are some performance regressions in ecosystem crates, 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
<p>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,
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
remove all uniqueness from <code>Box<T></code>, and treat it just like a <code>*const T</code> for the purposes of aliasing. This will make it more
predictable for unsafe code, and comes at none or only a minor performance cost.</p>
<p>But this performance cost may be real, and especially the future optimization value can’t be certain. I do think that there
should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be to use a
<p>But this performance cost may be real, and especially the future optimization value can’t be certain. The current uniqueness guarantees of box
are very strong, and still giving code an option to obtain these seems useful. One possibility would be for code to use a
<code>&'static mut T</code> that is unleaked for drop, but the semantics of this are still <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/316">unclear</a>.
If that is not possible, maybe exposing <code>std::ptr::Unique</code> (with it getting boxes aliasing semantics) could be desirable.
For this, all existing usages of <code>Unique</code> inside the standard library would have to be removed though.</p>
<p>I guess what I am wishing for are some good and flexible raw pointer types. That’s still in the stars…</p>
If that is not possible, exposing <code>std::ptr::Unique</code> (with it getting boxes aliasing semantics) could be desirable. For this, all existing usages of <code>Unique</code>
inside the standard library would have to be removed.</p>
<p>I guess what I am wishing for are some good and flexible raw pointer types. But that’s still in the stars…</p>
&lt;p>For more information about this topic, see &lt;a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/326">https://github.com/rust-lang/unsafe-code-guidelines/issues/326&lt;/a>&lt;/p></content></item></channel></rss>