Eh, it's hard to prove absence, and time is a beneficial quantity here. The longer something sits on nightly, the greater the chance that bugs are identified before it reaches stable and its usage significantly increases.
A lot of bugs with SIMD libraries are in the domain of interactions, not functionality--e.g. SIMD malfunctions on rare chips, chips with previously-unseen combinations of hardware/userspace firmware/microcode behavior, compilers run in weird harnesses that lie about hardware capabilities, and so on. I assume that's the case with Rust's portable SIMD as well.
If your QA is unpredictable individual use-cases (as with most OSS projects), then there's no way to measure "testing complete" or "coverage"; letting it bake for awhile is the best approach available.
Comments
It's a bad thing when there are no breaking changes done and they stabilize the exact same thing a few years later
Eh, it's hard to prove absence, and time is a beneficial quantity here. The longer something sits on nightly, the greater the chance that bugs are identified before it reaches stable and its usage significantly increases.
A lot of bugs with SIMD libraries are in the domain of interactions, not functionality--e.g. SIMD malfunctions on rare chips, chips with previously-unseen combinations of hardware/userspace firmware/microcode behavior, compilers run in weird harnesses that lie about hardware capabilities, and so on. I assume that's the case with Rust's portable SIMD as well.
If your QA is unpredictable individual use-cases (as with most OSS projects), then there's no way to measure "testing complete" or "coverage"; letting it bake for awhile is the best approach available.