[Arech]

In most cases (and this was the case of Mozilla I referred to) it's only a matter of compiling code that already have all support necessary. They are using some upstream component that works perfectly fine on my architecture. They just decided to drop it, because they could.

[sparkie]

It's not only your own software, but also its dependencies. The link above is for glibc, and is specifically addressing incompatibliy issues between different software. Unless you are going to compile your own glibc (for example, doing Linux From Scratch), you're going to depend on features shipped by someone else. In this case that means either baseline, with no SIMD support at all, or level A, which includes SSE4.1. It makes no sense for developers to keep maintaining software for 20 year old CPUs when they can't test it.

[johnklos]

> It makes no sense for developers to keep maintaining software for 20 year old CPUs when they can't test it.

This is horribly inaccurate. You can compile software for 20 year old CPUs and run that software on a modern CPU. You can run that software inside of qemu.

FYI, there are plenty of methods of selecting code at run time, too.

If we take what you're saying at face value, then we should give up on portable software, because nobody can possibly test code on all those non-x86 and/or non-modern processors. A bit ridiculous, don't you think?

[sparkie]

> You can compile software for 20 year old CPUs and run that software on a modern CPU.

That's testing it on the new CPU, not the old one.

> You can run that software inside of qemu.

Sure you can. Go ahead. Why should the maintainer be expected to do that?

> A bit ridiculous, don't you think?

Not at all. It's ridiculous to expect a software developer to give any significance to compatibility with obsolete platforms. I'm not saying we shouldn't try. x86 has good backward compatibility. If it still works, that's good.

But if I implement an algorithm in AVX2, should I also be expected to implement a slower version of the same algorithm using SSE3 so that a 20 year old machine can run my software?

You can always run an old version of the software, and you can always do the work yourself to backport it. It's not my job as a software developer to be concerned about ancient hardware unless someone pays me specifically for that.

Would you expect Microsoft to ship Windows 12 with baseline compatibility? I don't know if it is, but I'm pretty certain that if you tried running it on a 2005 CPU, it would be pretty much non-functional, as performance would be dire. I doubt it is anyway due to UEFI requirements which wouldn't be present on a machine running such CPU.

[johnklos]

> Would you expect Microsoft to ship Windows 12

There's the issue. You think that Windows is normal and an example of stuff that's relevant to open source software.

If people write AVX-512 and don't want to target anything else, then fine. But then it's simply not portable software.

Software that's supposed to be portable should be, you know, portable.

The implication is that you can decide to not support 20 year old CPUs and still have portable software. People who think that are just ignorant because if software is portable, it'll work on 20 year old CPUs. The "20 year old CPUs" part is a red herring, since it has nothing to do with anything aside from the fact that portable software will also run on 20 year old CPUs as well as different CPUs.

As an aside, instead of making up excuses for bad programmers, you might be interested to learn that software compiled with optimizations for newer amd64 didn't show any significant improvement over software compiled for all amd64.

Also, you have things backwards: code written and compiled today and run on 2005 CPUs wouldn't be "pretty much non-functional, as performance would be dire" unless you're talking about Windows. This is a problem with programmers and with Windows, and targetting the newest "features" of amd64 doesn't fix that. Those things aren't even related.

It's interesting how many people who either don't understand programming or who intentionally pretend not to want to make excuses for software like Windows.

[yjftsjthsd-h]

> Unless you are going to compile your own glibc (for example, doing Linux From Scratch),

It's not that hard to use gentoo.