It’s again the time of year when the Rust Core Team calls for blog posts for input into the next year’s roadmap. This is my contribution. It’s mostly a re-run of my Rust 2018 and Rust 2019 posts.

Apart from the LLVM bound check optimization item, the theme here continues to be: Please mark features that have worked since 2015 as done.

Promote packed_simd to std::simd

Rust has had awesome portable (i.e. cross-ISA) SIMD since 2015—first in the form of the simd crate and now in the form of the packed_simd crate. Yet, it’s still a nightly-only feature. Please promote packed_simd to std::simd (on stable) in 2020.

At this point, people tend to say: “SIMD is already stable.” No, not portable SIMD. What got promoted was vendor intrinsics. This is the same non-portable feature that is available in C. It’s bad if the most performant Rust code is built for x86_64 while aarch64 is left as a mere TODO item (not to mention less popular architectures). The longer Rust has vendor intrinsics on stable without portable SIMD on stable, the more the crate ecosystem becomes dependent on x86_64 intrinsics and the harder it becomes to restructure the crates to use portable SIMD where portable SIMD works and to confine vendor intrinsics only to specific operations.

Rust has an awesome better-than-C feature in portable SIMD. It feels tragic how underappreciated this seems to be. With portable SIMD, you can make things fast not just on x86_64 but on other architectures as well. You can still use conditional compilation to provide ISA-specific versions of particular operations within a larger algorithm when a given ISA has instructions that are more efficient than the generic approach, but you don’t need to commit to one ISA for the whole algorithm. It would be a major blunder to let C++ gain portable SIMD before stable Rust—when Rust has had the feature in an operational form since 2015.

Every passing year a new part of Firefox becomes faster thanks to relying on portable Rust SIMD: first encoding conversions at the IO boundary, then XPCOM string conversions, now SpiderMonkey strings. It’s not great that the feature continues to have the not-yet-stable cloud hanging over it. Can 2020 be the year when portable SIMD makes it onto the Rust roadmap?

Non-Nightly Benchmarking

The library support for the cargo bench feature has been in the state “basically, the design is problematic, but we haven’t had anyone work through those issues yet” since 2015. It’s a useful feature nonetheless. Like I said a year ago and the year before, it’s time to let go of the possibility of tweaking it for elegance and just let users use it on non-nighly Rust.

Better Integer Range Analysis for Bound Check Elision

See my Rust 2019 post.

likely() and unlikely() for Plain if Branch Prediction Hints

Like benchmarking, likely() and unlikely() are a simple feature that works but has stalled due to concerns about lack of perfection. Let’s have it for plain if and address match and if let once there actually is a workable design for those.

No LTS

Rust has successfully delivered on “stability without stagnation” to the point that Red Hat delivers Rust updates for RHEL on a 3-month frequency instead of Rust getting stuck for the duration of the lifecycle of a RHEL version. That is, contrary to popular belief, the “stability” part works without an LTS. At this point, doing an LTS would be a stategic blunder that would jeopardize the “without stagnation” part.