OS support and CPU support are different in my opinion. Old operating systems are, in a lot of cases, freely updatable (which is not always possible or easy, but often is). More importantly, old operating systems come with all sorts of problems (security) that mean that no one should be using them anyways. But old CPUs have no such problems, they're slow but run perfectly fine. I think we should be quite conservative with CPU support, and I'd rather see us look more towards making multiversioning and target feature detection easier than raising the baseline.
4 Likes
that's not quite true, e.g. a lot of older cpus have Spectre-style bugs that were never fixed because they're so old the manufacturer didn't bother, e.g. as far as they can tell the Pentium II should be vulnerable to Meltdown but is so ancient that I expect no one bothered to try to produce updated Microcode to fix that. I'd guess the same thing happened for the 64-bit versions of the Pentium 4 which uses the x86-64-v1 ISA.
3 Likes
It may depend on the OS too. I imagine that many people are still running old hardware with Linux, but Windows 10 probably requires x86-64-v2, so if it is actually the case, it would be possible to enable it on x86_64-pc-windows-*.
2 Likes
Windows baseline features were already bumped in Enable CMPXCHG16B, SSE3, SAHF/LAHF and 128-bit Atomics (in nightly) in Windows x64 by CKingX · Pull Request #120820 · rust-lang/rust · GitHub Apparently SSE4 is not a requirement, so that's not -v2 either.
1 Like
Which is an interesting challenge for Linux - Rust Windows will generate faster binaries in some cases just because Windows mandates a minimum CPU version.
I think the argument about what percentage use a given CPU is a side track. It's clearly going to be an overwhelming majority regardless of the skew in your data collection (you could argue that no one is trying to run Rust programs on older CPUs). The more important thing is that this doesn't drop support for older CPUs. Developers targeting those CPUs can change a flag and rebuild.
The question about the stdlib is interesting and I don't have a good answer. I think ideally it would make the most sense to have separate prebuilt stdlibs rather than targeting the lowest common denominator.
1 Like
That same argument can be made in either direction though. You can just change to a newer architecture if it is beneficial to your program.
You could argue that, but you would be wrong. I checked and the CPU I had in mind is v1. I do run Rust programs on it and it does its job just fine, so there's no reason to replace it. Sample size of one, but one is greater than none.
My binaries are distro supplied or compiled locally, and I pay attention to changes such as this one, so it's not going to be a problem for me personally. But after looking for other projects that have made such a change,[1] I'm pretty confident it will end up breaking things for other people.
Trying to gauge the extent of the breakage is entirely reasonable.