Re: C aggregate passing (Rust kernel policy)

[Ventura Jack <venturajack85@gmail.com>]

On Wed, Feb 26, 2025 at 10:52 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So "safe rust" should generally not be impacted, and you can make the
> very true argument that safe rust can be optimized more aggressively
> and migth be faster than unsafe rust.
>
> And I think that should be seen as a feature, and as a basic tenet of
> safe vs unsafe. A compiler *should* be able to do better when it
> understands the code fully.

For safe Rust and unsafe Rust, practice is in some cases the reverse.

Like how some safe Rust code uses runtime bounds checking,
and unsafe Rust code enables using unsafe-but-faster alternatives.

    https://doc.rust-lang.org/std/primitive.slice.html#method.get_unchecked
    https://users.rust-lang.org/t/if-a-project-is-built-in-release-mode-are-there-any-runtime-checks-enabled-by-default/51349

Safe Rust can sometimes have automated optimizations done
by the compiler. This sometimes is done, for instance to do
autovectorization as I understand it. Some Rust libraries
for decoding images have achieved comparable performance
to Wuffs that way. But, some Rust developers have complained
that in their projects, that sometimes, in one rustc compiler
version they get autovectorization and good performance,
but after they upgraded compiler version, the optimization
was no longer done by the compiler, and performance suffered
from it.

Best, VJ.