Removing 32 bit hardware support frees up die space and it frees up storage space and RAM since 32 bit and 64 bit libraries had to be on disk and in memory.

▲

fluoridation 6 days ago | parent [-]

They don't use memory if they're not used, but you do save storage. Neither one has any effect on power efficiency, though. None of these savings require the hardware to lose useful features. Microsoft could at any time decide to drop WOW64.

Saving die space also has no effect on power efficiency, beyond reducing the total transistor count. I'd be very surprised the x86-specific decoding logic makes up a significant area of your typical die. Maybe you'd make the processor 3% more efficient? Something like that?

▲

scarface_74 6 days ago | parent [-]

If any 32 bit app is launched the shared libraries will be loaded. It’s not a big deal on Macs. But it is a big deal on iPhones.

I’m not sure how it works in the modern era. But back in the day there was also a performance cost when you had a mix of 16 bit code and 32 bit code in memory. I don’t know how it would be in 32 bit vs 64 bit.

And being able to get away with less RAM also improves battery life because keeping RAM refreshed uses energy - again a bigger factor on mobile.

The smaller the die, the less energy it uses. You can also use that space for efficiency cores.

▲

fluoridation 6 days ago | parent [-]

> If any 32 bit app is launched the shared libraries will be loaded.

Like I said, if the 32-bit stuff is getting used, that's an argument not remove the support.

> And being able to get away with less RAM also improves battery life because keeping RAM refreshed uses energy - again a bigger factor on mobile.

Memory allocation exists purely at the software level. The hardware doesn't understand whether a particular region has been allocated or not; the only difference between an allocated page and an unallocated one is that the former appears in the OS's VMM data structure as allocated (i.e. it's just more bits in memory). The power consumption of RAM scales with the total cells installed, not with how much the OS has decided is "in use".

▲

JustExAWS 6 days ago | parent [-]

That’s what I’m saying - iPhones have traditionally come with less memory than Android phones of the Dane generation. Apple has been able to get away with it.

So should Apple have also kept the PPC emulator around for Macs?

	▲	fluoridation 6 days ago \| parent [-]
		>That’s what I’m saying - iPhones have traditionally come with less memory than Android phones of the Dane generation. Apple has been able to get away with it. There's no such thing as "how little RAM you can get away with". A user is always better served by having more RAM. The limiting factor is the monetary budget, not the power budget. If a manufacturer puts less RAM on a computer it's only to cut costs, not as a power optimization. Compared to the CPU, RAM is free, power-wise. In fact, since optimizing for space is often in opposition to optimizing for time, having more RAM can save power by saving time spent computing things. >So should Apple have also kept the PPC emulator around for Macs? I'm not really interested in discussing what compatibility support should be included in any given OS. It's not the topic of discussion. The topic of discussion is whether cutting x86 support from x86-64 processors would result in significant power savings, and I maintain that it wouldn't. It would result in at best marginal power savings at the cost of a useful feature.