Consider that CPUs on newer nodes consume less energy. There are special embedded low-power chips (eg TI 16 bit MSP), but they are NOT running Linux, and they never will. They couldn't reach their power targets running Linux, not even close. So I'm not sure obsolete designs being manufactured on old process node being kept alive is a net win. The special low-power cores are unaffected, as they are not running Linux anyway, and the ones that do aren't particularly low power.

There is a sweet spot for low cost chips, I think its 40nm due to mask costs, manufacturing gets exponentially more expensive from that point on, which is the reason they haven't upgraded. Anyone knows if there are signs this cost is coming down over time?

> Consider that CPUs on newer nodes consume less energy.

I think the main point is to use 32bit on new nodes too. Using 32bit instead of 64bit is always more energy efficient unless perhaps you really need 64bit for your application, which most applications don't.

This is a good point. I think this won't happen though, because smaller nodes are that much more expensive, and the market for energy-efficient 32bit CPUs isn't nearly large enough to fund development. There likely won't be another ARMv7.

What I think will happen is that the huge amount of money that goes into developing mobile phone SoCs, which are clearly trending towards 64Bit while still requiring low power consumption, will cause that technology to trickle down and be used in ever lower cost markets as time passes and those initial costs have been recouped. The Apple M1, as a system, is clearly crazy power efficient, even at 5nm. And again, if you need an ultra-low power sleep mode, because you only wake up once a day to send some sensor data out, its probably not running Linux in the first place.

I think you get into practical problems at some point. WikiChip lists a 28nm Cortex-A7 core at 0.48mm², with every node shrink (20nm, 14nm, 10nm, 7nm, ...) you can halve that, but adding 64-bit support to a core might only add about 10%.

You can't make chips arbitrarily small, because you end up wasting more of your wafer for the area between the dies and for the wire bond pads. If the chip size stays the same but the CPU gets smaller, most of the chip is for off-core components and the CPU has less impact on the total cost and power consumption.

You could use more complex CPU cores, or simply more cores, for better performance, but then you also need a faster memory interface (wider buses, LD-DDR4+ instead of DDR3, ...) to make actually use of the performance. These lead to higher memory capacity as well, but then you can't actually use the available memory as you run into 32-bit addressing limits.

I wouldn't rule out shrinks of existing 32-bit SoC families to 22nm or below to lower cost once those processes get cheap enough and there is still demand for compatibility, but there is a good chance that 28nm SoCs is where 32-bit ends. (note that I'm not talking about the dozen or so additional ARC/Xtensa/RV32/Cortex-M/... microcontroller cores on high-end SoCs, as those are not the ones running Linux).

Why do you think it's always more energy efficient?

Because less transistors need to switch.

I'm honestly curious how that plays out in practice. 64b Intel CPUs can run in 32b mode. If we count actual switching then we would end up with ~same usage. But in 64b mode it gives us both longer pointers and offsets it with fewer instructions on vector operations.

I could not find any actual paper with real use case comparison. Have you got one?

I haven't got a reference, and would be interested in one too.

Sure, if you use any kind of 32bit mode then you'd use less energy in theory. But if we leave the responsibility to the software developer, then we all know what happens :)

How much energy would this save? Of all the energy usage on the planet, this seems like it would be really really tiny.

That sweet spot for cost has already moved from 40nm to 28nm for most of the market. The new SAM9X60 I mentioned is still on 40nm, but it's a tiny chip and all new Cortex-A7 SoCs and things like the Ingenic X2000 are on 28nm because of overall cost for that design point.

The sweet spot for power efficiency has apparently moved from 28nm to 22nm, which uses less energy than either 28nm HKMG or 14nm FinFET and is also closing in on 28nm on cost.

There no mainstream 32-bit cores on 22nm or below (yet), so there is a good chance that the coming generation of low-cost 64-bit SoCs on 22nm will beat all 32-bit chips on performance, power consumption and cost.

Thanks, this is what makes HN good.

> Consider that CPUs on newer nodes consume less energy.

that's not entirely true. they consume less energy in run mode, but in deep sleep the leakage currents are higher than with larger nodes. this is relevant for ultra low power applications, but those don't run linux anyway.

This must be the reason Ryzens idle at higher power than Intels.

20 W of IO die power regardless of idling seems the more likely answer.

No, AMD has always been worse than Intel at idle power consumption. I don’t know the reason for the difference.

The reason nowadays is that desktop Zen chips run the I/O die at a worse node, to save money.

There is a real irony that the same post simultaneously complains about a CPU using slightly more power and also about not being able to ski for three months a year any more. Ski resorts and the attendant infrastructure like lifts and piste preparation machines are prodigiously expensive in terms of energy used per person.

I was not talking about downhill skiing. I have not done more than 5 hours of downhill skiing during the last 20 years. (Did a bit more when I was younger.)

I do only cross-country skiing.

Could also call it an irony that if mention a concept with 2 variants, the reader automatically assumes the more commercial, the more industrialized, the more polluting variant today.

Because on the planetary scale it is a bigger deal than ski resorts (affordable only to the citizen of the first world anyway).

> What about sustainability? Of course it's cheap to build ever more powerful systems and to ruin the planet with more energy consumption and more waste.

Are you sure that running two production lines and supporting both of them long term is more sustainable than killing one of them?

> By law of physics they could be built using less resources during production and during their lifetime.

If you want to go that way, why not even more efficient arm cortex?

there is more than one manufacturer to produce CPUs, so there are already more than two production lines

I'm not sure what you're trying to say. Regardless of the number of existing manufacturers, different architecture means more designers, validation, production pipeline and other inefficiencies. And that's best case of using the same wafers as your other products and not building a separate literal production line.

> 32 bit systems are good enough for many purposes

For all purposes actually in my case. The best notebook I've ever bought was/is the HP EliteBook 2530p; it runs 12 hours on battery, more than I need for my work day. I bought a new one in 2009 and a couple of used ones and parts since then. Most of my software and firmware development happens on this machine (Linux i386; I also have to support macOS though). It always works, never had downtime (I can replace parts within minutes if need be). Even Netflix works. And of course also all the embedded systems I produce are 32 bit, about half of them with Linux (the others are microcontrollers).

But how much energy and man power would it cost to support 32-bit CPUs longterm in all software?

I 1000% agree. Not everything needs 64bit. This is forced manufactured obsolescence

Linux is pretty much the original open source project. Just fork the repo and maintain 32 bit code yourself if you want to keep it.

> Linux is pretty much the original open source project

It's not. GNU pre-dates Linux by nearly 10 years. But even if you're talking strictly about kernels, 386BSD and Hurd were started before Linux.

> Just fork the repo and maintain 32 bit code yourself if you want to keep it.

I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial.

> I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial.

That was the joke, yes. The post I was responding to was complaining about "forced" obsolescence while there is nothing of the sort. Upstream maintainers want to drop some legacy code so they can spend more time on newer machines. GP apparently does not want to upgrade and is now complaining that other people don't do the non-trivial work of keeping 32 bit linux updated for free.

Maintaining a 32bit Linux fork which includes just security patches and (critical) bugfixes would actually be a lot less work than keep maintaining 32bit support for all new feature development. Maintaining a "32bit LTS" fork of Linux like this would probably be pretty viable.

Keep in mind that in this space, "security patch" might come in the form of rewriting the architecture specific virtual memory implementation... https://lwn.net/Articles/741878/

You'd hope that we're finished with working around all the CPU bugs now, but yeah, it's not necessarily trivial, and the longer the fork exists, the harder it will be to backport patches. But I can see how you can build a business maintaining a Linux LTS (there are businesses offering Rails LTS, Microsoft offers updates for Windows XP if you pay), so there's some precedent here.

It's also nontrivial for the people currently maintaining the Linux kernel. I interpret the "just" as a way to hint that forcing someone else to keep doing something for free, you could just do it yourself.

You could argue the same for 16 bit CPUs. If the vast majority of CPUs sold are 64 bits, we will to a point (we are already halfway there) where 64 bit CPUs could be cheaper (more competence and variety) and even more energy efficient.

While 16 bit CPUs are good for many purposes, these are not the same purposes where you have run Linux ever and where 32 bit is currently being replaced by 64 bit. So the analogy is not helpful.

Maybe 64 bit CPUs can get more resource efficient than older 32 bit models. But that's a misdirected use of resources if you use such technolgy to make 32 bit CPUs obsolete. With the same technology 32 bit will always use less resource-demanding than 64 bit. And the claim was that 32 bit has so many use cases (basically all phones and many PCs) that economics of scale are possible.

Of course the nonsense model that you don't pay for Internet services directly, but use Javascript and a lot of other bloat software to run advertisements on your phone to pay via a massive detour is not an energy-efficient approach.

linux never ran on 16 bit CPUs. that being said, CPUs like the 8051 are still very much alive today.

> linux never ran on 16 bit CPUs.

https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset

This was a toy project that was never mainlined

It doesn't need to mainlained in the same Linux upstream to be serious.

I am not familiar with it to say whether it really wasn't that useful for inherent reasons or whether vendors in that space were just more lucky to defend their proprietary solutions than the (mainline) Linux competitors.