Hacker News Reader

Comment by qcnguy | Hacker News Reader

And the more relevant case for laptops is macOS, which is heavily optimized for battery life and power draw in ways that Linux just isn't, neither is Windows. A lot of the problems here can't actually be fixed by intel, amd, or anyone designing x86 laptops because getting that level of efficiency requires the ability to strongly lead the app developer community. It also requires highly competent operating system developers focusing on the issue for a very long time, and being able to co-design the operating system, firmware and hardware together. Microsoft barely cares about Windows anymore, the Linux guys only care about servers since forever, and that leaves Apple alone in the market. I doubt anything will change anytime soon.

View on HN

>And the more relevant case for laptops is macOS, which is heavily optimized for battery life and power draw in ways that Linux just isn't, neither is Windows.

What are some examples of power draw savings that Linux is leaving on the table?

There's no equivalent of AppNap if I recall correctly and drivers often aren't aggressive at shutting down unused devices, or they don't do it at all. Linux has historically had a lot of problems with reliable suspends too.

Power efficiency is very important to servers too, for cost instead of for battery life. But, energy is energy. Thus, I suspect that the power draw is in userland systems that are specific to desktop, like desktop environments. Thus, using a simpler desktop environment may be worthwhile.

It's important but not relative to performance. Perf/watt thinking has a much longer history in mobile and laptop spaces. Even in servers most workloads haven't migrated to ARM.

I used Ubuntu around 2015 - 2018 and got hit with a nasty defect around gnome online accounts integrations (please correct me if the words are wrong here). For some reason, it got stuck in a loop or a bad state on my machine. I have since then decided that I will never add any of my online accounts, Facebook, Google, or anything to Gnome.

I assumed the same thing, until I tested my hypothesis. KDE Plasma 6 uses less power on idle than just `Hyprland` (tiling WM) without anything like a notification daemon, idler, status bar, etc.

Were you able to find out why? This is very interesting and I'd never guess it.

If x86 just officially said “we’re cutting off 32-bit legacy” one day (similar to how Apple did), they could toss out 95% of the crap that makes them power inefficient. Just think of the difference dropping A10 offered for memory efficiency.

“Modern Standby” could be made to actually work, ACPI states could be fixed, a functional wake-up state built anew, etc. Hell, while it would allow pared down CPUs, you could have a stop-gap where run mode was customized in firmware.

Too much credit is given to Apple for “owning the stack” and too little attention to legacy x86 cruft that allows you to run classic Doom and Commander Keen on modern machines.

>If x86 just officially said “we’re cutting off 32-bit legacy” one day (similar to how Apple did), they could toss out 95% of the crap that makes them power inefficient.

Where do you get this from? I could understand that they could get rid of the die area devoted to x86 decoding, but as I understand it x86 and x86-64 instructions get interpreted by the same execution units, which are bitness blind. What makes you think it's x86 support that's responsible for the vast majority of power inefficiency in x86-64 processors?

Intel has proposed APX to address this. It does away with some of the 32-bit garbage that complicates design for no good payoff. Most importantly, it increases from 16 to 32 registers and allows 3-register instructions (almost all x86 instructions are 1-register or 2-register instructions). This would strip out tons of MOV instructions which was proven with AMD64 to have a decent impact on performance.

Reduced I-Cache, uop cache, and decoder pressure would also have a beneficial impact. On the flip side, APX instructions would all be an entire byte longer than their AMD64 counterparts, so some of the benefits would be more muted than they might first appear and optimizing between 16 registers and shorter instructions vs 32 registers with longer instructions is yet another tradeoff for compilers to make (and takes another step down the path of being completely unoptimizable by humans).

>This would strip out tons of MOV instructions which was proven with AMD64 to have a decent impact on performance.

Sure, but the topic is optimizing power efficiency by removing support for an instruction set. That aside, if an instruction isn't very performant, it isn't much of an issue per se. It just means it won't get used much and so chip design resources will be suboptimally allocated. That's a problem for Intel and AMD, and for nobody else.

ARM has THREE instruction sets. (four?) aarch32, aarch64, and various incarnations of Thumb. (A PI 5 supports all three).

Okay? x86-64 has like twenty extensions. What's your point?

The point was that, with respect to the effects of implementing multiple decode stages for multiple instruction sets, ARM doesn't have an advantage over x86 in that respect.

(M1 does, because they don't implement aarch32, or thumb).

From what I understood. It's not "32-bit instructions" that are the problem. It's a load of crap associated with those 32-bit processors. There's more to x86 than just the instruction set. Operating systems need to carry the baggage in x86 if they want to allow users to run on old and new processors.

Before addressing anything else, "software is complicated by having to support legacy stuff" is not a valid argument for removing that support at the hardware level. If a software developer wishes to design their software without that legacy support, that's their prerogative.

>Operating systems need to carry the baggage in x86 if they want to allow users to run on old and new processors.

What do you mean by this exactly? Are you talking about hybrid execution like WOW64, or simple multi-platform support like the Linux kernel?

WOW64 is irrelevant as far as power efficiency is concerned if the user doesn't run any x86 software. If the user is running x86 software, that's a reason not to remove that support.

Multi-platform support shouldn't have an effect on power efficiency, beyond complicating the design of the system. Saying that the Linux kernel should stop supporting x86 so x86-64 can be more power-efficient is like saying that it should stop supporting... whatever, PowerPC, for that same reason. It's a non sequitur.

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.

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?

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.

> 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".

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?

>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.

> “Modern Standby” could be made to actually work, ACPI states could be fixed, a functional wake-up state built anew, etc. Hell, while it would allow pared down CPUs, you could have a stop-gap where run mode was customized in firmware.

I'm confused, how is any of this related to "x86" and not the diverse array of third party hardware and software built with varying degrees of competence?

Reply on news.ycombinator.com