openSUSE makes baseline CPU requirements a little friendlier than feared The future direction of openSUSE distros is firming up and has ramifications for its business-focused offspring SLE and Adaptable Linux Platform (ALP). It's not all that often that specific sub-versions of the x86-64 spec come up, but you can expect it to happen a lot more often as the 64-bit x86 platform reaches 20 years old …
> Does anyone know if ALP is still going to support KDE?
Even today, SLE 15.x does not include KDE. The only GUI option is GNOME 3, or IceWM if you choose not to have a full desktop.
You need to add community repos to install KDE, and I suspect that if you do that, it is no longer supported. (This was not my area when I worked there, so this is not an _ex cathedra_ verdict.)
So I am going to take a guess and say that the answer will be "no".
A little confusing -- I mean, if they have that chart like in the other article, it makes it clear (although I'll note there's one error in that chart). I suppose x86-64-v2 etc. may be terms used by gcc. But basically, x86-64-v1 is any 64-bit Intel/AMD chip; x86-64-v2 means "SSE 4.2 support required." x86-64-v3 means "AVX2 required". x86-64-v4 means "AVX512 required." I'll note, the chart in the other article says x86-64-v2 indicates AVX required; I thought that was odd enough decision (since for Intel chips, only Sandy Bridge and Ivy Bridge have AVX but not AVX2..) in fact per Google that's not the case.
Anyway.. *phew*. I'm running Ubuntu as my main distro, but I do have an old Ivy Bridge system...
1) I do have an OpenSuse VM and this would keep it from running on there.
2) Actually, (honestly due to virtualization on Intel systems being a mess), virtual machines have some special requirements to be able to pass AVX, AVX2, AVX512 support through to the guest. In VirtualBox, you need a new enough version of it plus you need "Nested Paging" turn on. I mean, might not be a big deal, but it might be a rude surprise when your OpenSuse cloud instance drops dead because you have to fiddle with virtualization settings (or even worse, you have to persuade your cloud provider to fiddle with virtualization settings.).
3) At least they aren't picking x86-64-v4! What a mess, Intel deciding some new CPUs will *not* have AVX512 after it's been out for so long (... the "P"erformance cores support AVX512 but the "E"fficiency cores don't... instead of updating the "E" cores to support it even if it's slow.. which would be fine since the system could just schedule these processes onto "P" cores... instead, they removed AVX512 support via microcode.)
"To check the hardware for those running Tumbleweed, users can use the following command in a terminal.
/lib64/ld-linux-x86-64.so.2 --help
Results should likely result in the following:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)'"
From : https://news.opensuse.org/2022/11/28/tw-to-roll-out-mitigation-plan-advance-microarchitecture/
Also:
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
The whole point of x86 is backward compatibility.
Intel got its botty smacked with this stick when it tried to move the industry on to Itanic.
If software requires something which can't execute i386 opcodes, then what's the point? Just compile for Arm or Risc-V.
Windows, of course, is something else.
-A.
And x86 continues to be backward compatible even if certain things (like MMX and the FPU) are as near as makes no difference emulated nowadays (in particular, code mixing MMX and SSE will take a performance hit due to register sharing). This is about (software in) the OS compiled to require a higher baseline ISA than the one provided by OG Athlon64/64 bit enabled Pentium 4. You can (still[1]) run your old software on the new OS, assuming your CPU is new enough, or continue to run an old OS on an old (or new) CPU.
[1]: The 800lbs gorilla of 32bit libraries is Wine, and it's tantalizingly close to drop that requirement (nearly all 32bit wine libs can be linked against 64 bit versions of their respective native library dependencies, and work is ongoing to close that gap). Once that is achieved, I don't see many binary distributions maintaining proper multilib support on amd64.
> The whole point of x86 is backward compatibility.
I could be wrong here but it seems to me that you are confusing the directions here.
*Backwards* compatibility means that newer systems are compatible with older ones. The direction in time is from new _to_ old, hence, "backwards".
*Forward* compatibility means that future systems will still be compatible with existing ones: in other words, looking forwards in time.
Requiring a new version of the x86 ISA is not related to backwards compatibility; nobody is discussing removing features that were once present. This is the opposite: it is saying, "let us stipulate that we require a certain baseline set of facilities" which means requiring a system _newer_ than a certain cut-off.
Newer systems remain compatible with older ones. No backwards compatibility is lost here. This is about going forwards and advancing in time to newer system facilities. Old code will still run.
Linux dropped i386 support a decade ago in v3.8 in 2012. Your 386 code still works, though. If you have any.
Kernel 6.2 will drop i486 code next year. The minimum spec to boot a 32-bit kernel 6.2 will be i586, meaning Pentium 1 level or above. That is a 1993 CPU, meaning that kernel 6.2 will still function on hardware that is *thirty years old*.
Newer systems remain compatible with older ones. No backwards compatibility is lost here. This is about going forwards and advancing in time to newer system facilities. Old code will still run.
There are a few cases where backwards compatibility has been dropped. The historic gate A20 switch comes to mind. At first it was a motherboard feature, then a chipset feature before becoming a CPU feature when the memory controller moved on chip. At least it did until it was finally canned perhaps 10 years ago. Nobody really noticed, but how many people still work in 16 bit real mode?
Going the other way there comes a point where it makes sense to simply require new features. If you don't you end up with an ever increasing amount of code that is only used very rarely and in all likelihood not by the developers. Sometimes that code can be relatively self contained as is the case for FPU emulation for example, in which case yes it's a compiler switch. What about hardware AES? If you make the decision not to mandate it you have a decent chunk of code famously difficult to implement correctly that is lying unused for the majority of users. At a certain point it makes sense to no longer support options of interest to an ever dwindling number of users and make full use of advances in technology.
Someone explain: What is the point of these new "features"? Just to differentiate CISC from RISC by making things more complexxx?
Sure, AVX, AVX2, AVX512 work on big data, chokers we used to iterate over. How much everyday stuff NEEDS this?
Cryptography? How often do I log-in or share secrets? On a server, how often does login/handshake traffic approach data exchange traffic?
Once the compiler is written, compiler time is cheap. Far cheaper than buy-time checkbox-checking or, as said, trying to get your Cloud provider to give you a specific instruction set. Make the compiler emit both dumb-i386 code and snappy AVX-xxx code. At start-up time, poke the CPU (don't trust BIOS flags too far) and flag code junctures to use one or the other path.
And what when the snazziest new "feature" turns out to be open to hackers? Then a first-fix can be to turn-off that feature.
I ran 8088 in a day when "big math" (log, trig) wanted a 8087 math coprocessor. The average 8088 program optionally (but often by default) compiled-in a 8087 emulator. Working like Long Division, it could chew a LOG in seconds. The 8087 would do it in milliSeconds but was a $400 chip; most of us did not do that much math. I finally did, for electronic problems. But 10+X the speed on 10% of instructions did not make the result a lot faster.
Yes, the 386 does seem "slow" today. I have seen an early '386 struggle for a minute to render a simple 1995 web page. But sometimes the job is not about speed. And there are still legacy CPU cores in ASIC libraries.
Don't tell me it bloats the code! Windows, bah. Linux is growing opaque and humongous init and flatpack bloat. A little bloat to run code on ANY 386+ processor is more than justified today.
The point of (most) CPU features is performance gains
Sure, AVX, AVX2, AVX512 work on big data, chokers we used to iterate over. How much everyday stuff NEEDS this?
NEEDS is pretty much zero (everything can run in a Turing Machine :) ), BENEFITS is a whole other kettle,
Cryptography? How often do I log-in or share secrets? On a server, how often does login/handshake traffic approach data exchange traffic?
Full disk encryption is a thing y'know, and highly recommended for portable devices. And on servers, you really should be using encrypted traffic to the internet/intranet (as near as makes no difference a reality for HTTP, SMTP, and POP3/IMAP; domo arigato Mr. LetsEncrypt)
Once the compiler is written, compiler time is cheap.
Debugging time for each permutation of compiler/feature flags, however...
Make the compiler emit both dumb-i386 code and snappy AVX-xxx code. At start-up time, poke the CPU (don't trust BIOS flags too far) and flag code junctures to use one or the other path.
This is exactly what glibc (and a handful of other high performance libraries) do; One of i[456]86 introduced a CPU instruction to poke its features (CPUID) which works pretty well, and some libraries/programs even run benchmarks to select the codepath (mdraid on the Linux kernel comes to mind). This does increase the load time of each program and the complexity of the build system, however
But 10+X the speed on 10% of instructions did not make the result a lot faster.
Anecdata: One of my workmates is trying to run 1000s of EE simulations using Python. On a ~2014 Xeon CPU (with ECC DDR3 or similar memory), each simulation takes ~30 minutes. On his 2018 Ryzen 2xxx CPU desktop computer (and in my 2019 Ryzen 3900 desktop computer at home, both with DDR4 memory) each simulation takes ~6 minutes. (the I/O of each simulation is barely within/below the order of double digit MBs)
And there are still legacy CPU cores in ASIC libraries.
None of which are likely to run a full-fat General Purpose Linux Distro anyways (or even a not in-house binary distribution at all)
A little bloat to run code on ANY 386+ processor is more than justified today.
Counterpoints:
- glibc has long since dropped support for < i586 (and even i586 IIRC), by accident (by the time somebody noticed, upstream glibc decided to drop support instead of fixing the bug)
- Performance per watt of old CPUs vs a Raspberry Pi 4 or similar
- i386 support has long since gone from Linux due to missing basic instructions to implement atomics (xchg, cmpxchg), and Linux devs are trying to raise the minimum to i586 due to maintenance burden
DoContra, Liam-
Thanks for your thoughtful responses.
They almost confirm my suspicion. New instructions are minimal benefit.
"~2014 Xeon CPU... ~30 minutes. ...2018 Ryzen 2xxx CPU ... ~6 minutes.
This looks like pure hardware. Faster clock, fewer cycles per instruction, deeper caches facilitating more speculating. Is there even any difference in the code being run? 4 years is 2.66 Moores or 6.3X faster, so 30min to 5min. (The other minute is super-chip to consumer chip, i.e. price.)
And XCHG ??? That's what, a 1-cycle optimization? If that? On the 8086, it seems half as fast as MOV, suggesting a macro or at most a hidden 16-bit register.
If compilers stuck at i586 features (with *maybe* the large-array graphics used by FPS gamers), maintenance burden would about vanish.
And I just can't believe that all our disk encryption and all our network encryption add up to a significant load, except the corner case of very secure very tiny payloads. I'd believe that rendering high-res porno videos from compressed to screen is a load, but apparently tolerable.
> What is the point of these new "features"?
The cynical answer:
Moore's Law didn't predict CPU speeds would increase: in fact it predicted that the number of transistors per unit cost would increase.
CPU designers are looking for ways to use those additional transistors. They have been for decades.
In the 1980s this meant microprocessors handled wider and wider words: 8 bit, then mass-market 16-bit, and relatively early expensive 32-bit.
In the 1990s, this meant mass-market 32-bit, then early expensive 64-bit (DEC Alpha, etc.) In the mainstream, CPUs gained onboard L1 cache, then onboard L2 cache, and went scalar (instruction pipelining) and then superscalar (multiple instruction pipelines).
But also, the Pentium MMX was the first CPU generation to add new instructions to i386 with MMX -- although most software didn't use MMX, and in fact, it was doubling the onboard L1 cache which made the Pentium MMX 15-20% quicker in general execution speed.
[Aside: I found and reported upon the first Pentium MMX in a mainstream PC in the UK: an engineering sample CPU submitted without notice by Evesham Micros to PC Pro magazine.]
In the 2000-2010, this meant going multiple dies in 1 package, then multiple cores on 1 die, and hyperthreading (multiple threads on each core), and about the time that multicore CPUs started to appear, x86 went 64-bit.
Now server chips can have more than a dozen CPU cores, each able to run 2+ CPU threads. However, Amdahl's Law means that this doesn't deliver real-world performance improvement on the desktop.
So, instead, desktop CPUs are not getting more cores. They are getting better and better hardware accelerated media encode and decode, hardware accelerated encryption and decryption and so on.
We all view web pages over HTTPS now and increasingly we view video and stream audio over those encrypted connections.
Thus, increasing amounts of dedicated hardware to accelerate certain, sometimes very specific, types of operation.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
