Repository navigation
Support for scalable vector types? #339
Description
Activity
This is a deliberate design choice. Having N as a compile-time constant helps with optimization quite a lot. Making it a runtime value would hurt performance on common devices. I really don't want to hurt performance on hardware used by billions of people just to support really obscure devices.
Once variable-sized vector ISAs become relevant, there are two ways we could support them in a backwards-compatible fashion. Either we can either add levels for specific widths, e.g. Sve128, Sve256, Sve512, etc. Or we can add a new trait for variable-width vectors with a runtime width but worse codegen on common platforms that people would have to opt in to if they want to support variable-width vectors.
Right now we really don't have to worry about SVE and RVV because as of 2026 they are completely irrelevant. Performance and price of SIMD-capable hardware RISC-V both remain completely impractical. Tenstorrent promises to change that, but their claims have not been independently verified, and their silicon tapeout is still 2+ years away. And SVE still barely exists: SVE2 is mandatory in ARMv9, but even ARM's high-end server CPUs only implement it in 128-bit width, so it's just NEON with extra steps. There was one server CPU generation with 256-bit SVE (not SVE2), but it was removed in the next generation, and only existed in the cloud anyway, where you're much better served by AVX-512.
Sounds like it's handled then. I'll close the issue.
Since fearless simd is approaching 1.0, I wanted to make sure it was OK that the current API is unable to support scalable vectors such as are found in ARM's SVE. In particular, the
SimdBasetrait has an associatedconst N: usize, which implies that the size of a given vector is known at compile time. If I understand correctly, the constantNwould need to be changed tofn n() -> usizesince the size of a theoreticalu8xdyntype would not be known to the compiler. There might be other issues too. I have not done a thorough examination.Right now a
u8xdyntype can't be implemented because the Sized Hierarchy traits would need to be stabilized, so this could be pushed off to a version 2.0. However, if I understand correctly, the Sized Hierarchy traits are blocked on const traits which are blocked on the new trait solver. The tracking issue for the new trait solver says that it will be enabled by default on nightly before the next stable release. So I don't think it will take years for the Sized Hierarchy traits to be implemented. Thus it might make sense to make the breaking changes need to support such a type before 1.0 even if the type cannot be implemented yet.