Sure, except this time also add on US pressuring Korean companies to not sell their old equipment to Chinese manufacturers, so the supply could actually keep up. But no no, it's all OpenAI's fault for behaving like the capitalistic swines they are. Both suck, but one has a long-lasting impact, the other is just what capitalists always done, and will continue in the future.
Agreed - it's more likely to lead to poor user experience than anything else. Most end-user facing software/service companies will probably bet on the DRAM price peak being temporary.
Software takes a lot of time to build. Codebases live for decades. There's often an impossibly large cost in starting over with a less wasteful architecture/language/etc. Think going from an Electron/Chromium app to something built using some compiled language and native OS GUI constructs that uses 10x less resources.
The impossibly large cost is the difference between hardware and software returns.
Hardware by nature forces redesigns whereas software it's always possible to just keep building on top of old bad designs, and so much cheaper and faster to do so. That's why hardware is 10,000x faster than 30 years ago, and even simple word processors are debatabely faster than 30 years ago. Maybe even slower.
Hardware isn't much better actually. There isn't a good way I can show you this, but every x64 CPU contains an entire ARM CPU whose job is to initialize the x64 CPU. And of course it runs two operating systems - TrustZone and Minix.
The ARM Core starts up, does crypto, Loads the SecureOS and the BIOS, then it starts the x86 CPU - In 16 bit mode! Which then boostraps itself through 32 then 64 bit mode.
So in the first couple sends of power on, your CPU is at various points ARM, i386, x86, and x86_64.
> The ARM Core starts up, does crypto, Loads the SecureOS and the BIOS, then it starts the x86 CPU - In 16 bit mode! Which then boostraps itself through 32 then 64 bit mode.
Well, what if I want to run a 16-bit OS?
Also, I wonder if the transistor count of a literal entire 8086 processor is so small relative to the total that they just do that.
Compatibility mode doesn't work by having a separate 16-bit core. It's random bits of spaghetti logic to make the core work like a 16-bit core when the 32-bit flag isn't set.
There isn't a separate 8086 core in every x64 core. The whole core has "if/then" spaghetti logic scattered throughout to alter its behaviour based on being in 16-bit mode.
At best, they might have been able to confine the needed logic patches to the instruction-decoding front end.
It began life as an "out of band" way to administer servers so that an ops. team could do everything (other than actual hardware changes) remotely that would otherwise need a person to be standing in front of the server in the datacenter poking commands into a keyboard.
It then grew in responsibilities to also support the "secure boot" aspect of system startup, and beyond some Intel CPU version point (I do not remember which point), it exists in every Intel CPU produced.
I remember being flabbergasted when I worked at the open source development lab and we got our first itanium system in, a multi-core, multi-rack nec system, with its own windows pc to boot up in order to get to linux.