Back to chips: They already sell partially working chips. So if a core if faulty (tested in the factory), it is disabled and sold as having less cores.
This way of working was already being used for the production of the
ZX Spectrum, they used
half-bad RAM chips where some 64K chips had the high and some had the low RAM faulty, which was disabled. So 64/2=32K + 16K = 48k
This is a good read about that ZX era (it was only a brief time):
The ZX Spectrum sold with either 16 or 48K RAM, necessitating an optional 32K memory bank which was achieved in a characteristically (for Sinclair) cleverly frugal way: with half-bad 64kbit DRAM ch...
retrocomputing.stackexchange.com
Note that the comments of that article might have a fallacy in respect to the
486sx being an 486dx with defective FPU.
The problem with the half-bad method is that it is risky, but if the shortage continues, it might give us extra chips what would have ended scrapped.
IBM does it the other way around, they sell you the machine with 64 cores, and only the ones you pay for are being enabled (so if you pay more, more are enabled by remote management).
Let's talk datacenters. The virtual machines do not use CPU's but timeslices of cores's, so you can assign a quarter of a core and run many machines on a single core. However, that's not all too efficient because each one of these has a separate OS running, which also requires some CPU time.
So the big solution for DataCenters, is to run containers. For example: Docker and Kubernetes. These increase some dependencies and make things more entangled. For example, upgrading the OS. And most Linux patches strongly recommend a reboot, so that's a lot of containers that need to go down. As containers do not have a v-motion style move-to-another-hardware-while-still-running, some of it is faked by making the application run multiple instances and putting a loadbalancer in front. The loadbalancer can then redirect al requests to the "other" node, while you reboot.
However, not all is perfect. Many applications can not be sliced up. Many applications require so much IO that they actually run better on dedicated hardware. Containers require a new way of making software; which is not available yet. Sure, the frontend of the application is webbased and easy to containerize. But the backend, that thing that connects to the database. That database requires so much IO that you are left with spare RAM and CPU, but your machines crawl slowly. There are some solutions, like a distributed database, where one node is used to read-only, and the other to read+write. Or use a RAM cache, but those are quite un-intelligent at the moment, unable to auto-optimize what to keep (no intelligent connection with dba_tab_modifications), what to pre-cache based on expected. This of course makes the software bigger and slower.
And that takes us to the second problem, that software is slower than in the past. It does too much redundant things. (Just try Ansible on the Pandora, loading the Python takes 15 seconds; and this has to be done for each command you input). Efficiency is not paramount anymore. Just try to create an Oracle table with "hello world" and see how much RAM and diskspace it requires to handle it. Otoh, these softwares, like say DB2, have auto-analizers that measure all incoming queries and is able to help create the required index files (which make queries much faster) for your particular case.
So from that side, the business market, there is no relieve coming. And it's worse in the consumer market, where we now have been Pavlov'ed into buying a new phone every 2 years. Because they sell you the phone plans with bundled mobile that way to maximize profit. Ah, so that means that we can expect that market to shrink and prices to go up.
Ok, this is longer than I wanted, and I'm too lazy to condense the info and delete parts to stay on-topic. Sorry for that.
www.sparkfun.com
www.weforum.org
