> Why isn’t std::simd in stable yet?

Leaving aside any specific blockers:

- It's a massive hard problem, to build a portable abstraction layer over the SIMD capabilities of various CPUs.

- It's a massive balance between performance and usability, and people care deeply about both.

- It's subject to Rust's stability guarantee for the standard library: once we ship it, we can't fix any API issues.

- There are already portable SIMD libraries in the ecosystem, which aren't subject to that stability guarantee as they can ship new semver-major versions. (One of these days, I hope we have ways to do that for the standard library.)

- Many people already use non-portable SIMD for the 1-3 targets they care about, instead.

▲

colonial 10 hours ago | parent | next [-]

> Many people already use non-portable SIMD for the 1-3 targets they care about, instead.

This is something a lot of people (myself included) have gotten tripped up by. Non-portable SIMD intrinsics have been stable under std::arch for a long time. Obviously they aren't nearly as nice to hold, but if you're in a place where you need explicit SIMD speed-ups, that probably isn't a killer.

	▲	JoshTriplett 10 hours ago \| parent [-]
		Exactly. Many parts of SIMD are entirely stable, for x86, ARM, WebAssembly... The thing that isn't stable in the standard library is the portable abstraction layer atop those. But several of those exist in the community.

▲

vlovich123 12 hours ago | parent | prev [-]

> we can't fix any API issues.

Can’t APIs be fixed between editions?

	▲	JoshTriplett 12 hours ago \| parent [-]
		Partially (with upcoming support for renaming things across editions), but it's a pain if the types change (because then they're no longer common vocabulary), and all the old APIs still have to exist.