Video decode is part of the GPU, not CPU. They are on the same tile in Lunar Lake though.

Sure, there are ACPI bugs, they hit windows too. But to claim there are "works on windows but not linux" bugs everywhere is bogus. If it works in windows, it should work in linux too, that is the point of a platform power interface like ACPI. When one actually tries to look at why the battery life is worse in linux, or the machine doesn't resume properly, overwhelmingly what one finds are linux bugs. Bugs, like the distro won't ship accelerated video codec's, or hibernate is broken due to the kernel refusing to support it with secure boot on, or the wifi or GPU drivers have bugs in their suspend/resume paths, or even simpler things like there isn't a clear project/owner responsible for detecting seat activity and making power related decisions. Sure the freedesktop/dbus/systemd interfaces are there, but often a WM of distro will replace one of those components and create another set of bugs. Never mind desktop Linux still doesn't have the concept of a foreground/background application split so even if it wants to do scheduling hints indicating that a minimized chat application shouldn't be consuming 100% of a cpu when in the background no such standardized component exists unless one is running android. Systemd rightly gets a lot of shit, but it has standardized parts of this functionality, like for example how an application requests a screen inhibit. Nevermind it takes 2-3 years from the point a machine gets released before all the driver tweaks/etc land upstream, and trickle down to your average users machine.

Bottom line, linux on laptops only really works because of ACPI, if you were wondering what the laptop space looks like without it, I might suggest grabbing a couple random arm laptops/chromebooks and giving them a spin.

I don't trust anything in power management to work right on Windows (or Linux.) It is way better than it was in 2000 when I was working with a businessguy who had a Windows laptop that needed several hard reboots a day.

Right now I am listening to music on this computer while I work on another computer. When the screen turns off on this computer the headphones get switched to headset (telecommunications) mode and the music quality goes down... On a desktop computer where saving power is not a big issue and I certainly don't want worse audio just because the screen powered off.

It's been a long term issue that USB devices will not work properly if USB power management is enabled and that's scary when some of those devices are mass storage devices that could corrupt data.

As a single vendor, I trust Apple better to get things like this right, but I don't particularly like MacOS.

> Linux, xBSD or macOS compatibility? Forget it unless you're talking servers

I think you'd have a pretty hard time finding an x86 system that couldnt run Linux these days. If you gave me a random x86 machine from the past decade, I'd actually feel more confident installing Linux than Windows.

They don't call it "advanced" for nothin'.

FWIW the alternative these days is probably running a 32-bit RTOS on your battery hardware which isn't much simpler.

Yeah, that all makes senses. But having legacy software that you support has been a big advantage for x86 for, basically, forever. For a lot of purposes, that is way more important than performance per watt.

ah I didn't understand that your "syntax (faster)" referred to the compiler speed, I thought you were referring to the speed of development/engineering!

> Yes, the programming language defined in the 70s isn't perfect and has a couple of kinks that could be improved. As does every single programming language.

Back in the 70s, they didn't know as much about writing parsers as we do now. The field was much younger.

There is a reason that Go's declaration syntax is not based on C's, despite Go being created by one of the co-creators of C.

> which is the exact opposite of your unbelievable claim.

I'm not making claims, I'm stating facts. Parsing C declarations is difficult. Writing C declarations is difficult. Reading non-trivial C declarations is difficult. For examples of this in action read https://en.wikipedia.org/wiki/Most_vexing_parse.

C++'s horrific syntaxial complexity is the ultimate end of C-style decls. C++'s syntax is, again, objectively overly complicated for what it does. The reason it is overly complicated it because of the syntax it inherited from C.

C got some things right, mostly around ease of porting to different architectures. However, 50 years later we know a lot more about how to design programming languages.

C is not perfect, and even when it was created, better designed programming languages existed. However C was cheap and good enough, and because it was easy to port, it spread to lots of platforms.

FWIW I started my career in C/C++ compilers, I have first hand experience with these topics. I love C as a language, but I also acknowledge it is not perfect. The machines it was designed to run on in the 70s were not the height of Computer Engineering and C is not the height of programming language design.

Millions of flies can’t be wrong.

Or, more politely, a primer on how to confuse first-mover advantage with being any good.

C is abysmal by today’s standards, it being the first popular language for weak computers is literally what’s keeping it popular. Popularity is very valuable but please don’t confuse it with being good.

> your unbelievable claim

Please quote the specific claim you think is unbelievable.

(I assume you don't mean the declarations claim because you didn't even disagree with it.)

I got that, but it's not a good analogy. It's the parser that is to the language what the CPU is to the instruction set

I agree. It's getting more and more pointless to avoid SoC. No need to do expensive bus transports when you can just stay on-die. The only upgradeability that's needed is to swap out entire SoCs.

They take full power and subtract idle power.

Geekbench shows the same gap in performance. Cinebench has historically favored Intel chips more than Arm.

It doesn't necessarily use half the power. But it does have greater than 2x in perf/watt and it has noticeably faster ST performance.