How do you optimize for a system architecture that doesn't exist yet?

(e.g. CoD could probably be fixed quite easily, but you can't do that before the hardware where that problem manifests even exists - I'd say it's much more likely that the problem is in the Windows scheduler though)

> Games requiring desktop cases looking like a rainbow aquarium with top everything will become a niche

PC gaming has been declared dead ever since the late 90s ;)

Is Linux even usable on laptops still? I've got a number of machines that still seem to fail to wake from sleep on even most recent and common distros.

Is Mac even usable on laptops still? I've had a lot of coworkers and friends with Macs still run into hot bag situations often.

> Between the waking from sleep to check notifications

Its rarely ever actually Windows that's causing the issue. Almost always crappy drivers and crappy hardware that causes the wake. Disabling allowing wake from sleep on whatever crappy hardware is causing the sleep problems is almost always the answer.

I recently spent some time trying to figure out why my Lenovo Legion Go was waking from sleep. I could put it to sleep and it would almost always wake up within an hour. There's a nice utility in Windows to help analyze power patterns on the system called powercfg which will give you a good report with powercfg /sleepstudy . Turns out one of the USB4 controllers was using a stupid amount of power while asleep which would cause the system to wake. Disabling that USB4 controller to wake the system from sleep meant it wasn't even partially awake and thus stopped using so much power and would not cause the system to wake. Now the device has been asleep for many hours and hasn't woken up once unexpectedly. It also is getting less battery loss sitting on the desk asleep than it had previously.

Also most of this is intentional first party behavior from Microsoft. Windows intentionally periodically wakes from sleep to do communication (for notifications etc.) Microsoft's advice last I checked is to not store sleeping laptops running windows in laptop bags.

There's a ton of other decisions they've made that just make the OS incredibly unpleasant on any device with mediocre cooling and a battery. That's why I wrote post: is it bad enough yet that it's intolerable.

Serious question, specifically what is wrong with the driver model in terms of this situation? What change would you propose to solve this? Why isn't it a matter of the device manufacturers churning out crappy and poorly tested devices and solely Microsoft's fault?

I do agree, Microsoft should probably make it easier to point out "hey this device is causing your system to wake, here's some potential fixes", as reading the powercfg /sleepstudy takes a little bit of deeper computer knowledge. But in the end a crappy driver and bad hardware is going to be a crappy driver and bad hardware. Should Windows just refuse to work at all with said crappy hardware?

Especially considering I've had so many other devices which don't have these problems. If it was truly the OS that was at fault, why isn't the issue with every device running the OS instead of only some devices with some hardware and firmware versions?

> Microsoft's advice last I checked is to not store sleeping laptops running windows in laptop bags

Got an official source for that claim?

> Therefore, we highly recommend that all customers do not put the Surface in their bag while sleeping, as this can indeed cause overheating.

> Best Regards,

> Mitchell | Microsoft Community Support Specialist

Sleep has worked pretty much fine on the vast majority of the Windows computers I've owned/managed, outside of a few troublesome devices such as this Legion Go and some network cards that would wake on any activity.

Meanwhile about half of my Linux machines over the years routinely fail to wake from sleep. Even today I still get issues on a modern-ish Thinkpad that fails to resume from time to time but which slept perfectly fine in Windows 10 and Windows 11 every time.

> It's not uncommon to have some slowdown, open up Task Manager and seeing some process I-don't-know-what-it-does pinned at 99% CPU usage

Yes, and I'm sure if an average user used ps aux on Linux they'd know what everything in that list is doing.

Good for you, and I believe you. However you're the only person I've ever met with this sentiment. IME even multi-thousand dollar Windows laptops do not sleep right.

Luckily, it kind of works out. Windows rots if it's left un-rebooted for a few days so forcing reboots with broken sleep almost optimizes the Windows experience.

> Yes, and I'm sure if an average user used ps aux on Linux they'd know what everything in that list is doing.

Fair, but they also don't need to. I never, ever have this problem on Linux. We do have background processes but they seem to be written by people who are, I'm assuming, not asleep. They work fine. Even file indexers like baloo work correctly. I can find any file on my computer on the order of milliseconds, and I never have high CPU usage. I'm being a bit cheeky here - it's very easy to hate on Windows search so I shouldn't be bragging about functional search.

There was that one Windows handheld recently that released a SteamOS version, but I can't remember the name. Anyway sleep works correctly on the SteamOS version, though that's mostly valve's work with properly suspending games. Oh and it gets an extra hour or so of battery. But the tradeoff is... wait... 10% extra performance in games? Through the translation layer? Wow, that's shocking.

Point being, Windows on battery-enabled devices is truly ass. The bottom of the barrel of experiences. It becomes evident when you try out other devices. I have a switch. I press the power button and it turns off. It turns back on instantly. The power doesn't drain. And, my game is right back where I left it. I didn't restore from a save. I'm not on the main menu. It literally suspended the entire state of the game and un-suspended it like nothing happened. That's unthinkable on Windows.

I would never, ever put my Windows laptop to sleep with an unsaved Excel sheet open. If it wakes up, there's a good chance that application is mysteriously restarted. I don't trust anything on Windows.

It is the device I mentioned earlier. The same device I suggested wasn't sleeping right. And now sleeps fine for me, now that I've disabled that device from waking the machine.

> I never, ever have this problem on Linux

Good for you, and I believe you. I've experienced runaway processes many, many times on Linux systems. Its great when the desktop session gets completely locked up so I have to hop on a different tty to go kill something because the machine is just too overloaded.

> Oh and it gets an extra hour or so of battery. But the tradeoff is... wait... 10% extra performance in games?

Once again, I'd point to crappy drivers. Lenovo has been really slow to actually push graphics drivers on their devices. And Lenovo's tools for managing power profiles is pretty bad, if the reviewer wasn't manually changing between power profiles that could easily have explained those big battery life deltas. And once again that's a Lenovo thing, they really push managing the power profiles in their Legion app instead of using any kind of good profiles in Windows itself. I play pretty similar games to those games he reviewed with big battery life deltas, and I get roughly the same battery life as he did running SteamOS.

> The bottom of the barrel of experiences

I constantly get sleep issues on my Linux hardware where it just fails to resume and sits at a black screen or throws kernel panics. I've got coworkers whose external displays don't get reconnected right from sleep. These are pretty bottom of the barrel experiences. Meanwhile, every one of my Windows machines sleeps and wakes without any issues.

Again, I believe you, but I've never seen this and I don't know anyone else who has ever seen this. Everyone I've ever talked to, ever, has said sleep on Windows does not work. That's a big reason they're on Macs.

Now, I don't like MacOS. So I use a Lunar Lake laptop with Linux, and sleep works. I have 2 1440p 240hz monitors connected over thunderbolt and those sleep and wake just fine too. Which, as an aside, is a testament to the hardware. Shoutout Intel.

And on the topic of drivers, yeah that's just a roundabout way of critiquing Windows. Those should be included in the kernel. It was a design choice to not do that, which really holds Windows back. Microsoft has been reversing course over the past 10 years or so, so we have precision drivers from Microsoft for touchpads for instance.

And, surprise surprise, those touchpads with first-party precision drivers built into Windows are the best touchpads.

https://discussions.apple.com/thread/250999629

As for drivers being in the kernel or outside the kernel, in the end if the vendor writes trash drivers they'll be trash drivers regardless of where they are. Clearly good touchpad drivers could have been written, but Synaptics just never gave a shit. But those same shitty touchpads were still often shitty even in Linux with open-source drivers. And what do you know, a vendor actually cares to make a good driver and things are better. We didn't even need to change the entire driver model for it to happen.

Back when I used nvidia graphics adapters a driver crash in Windows just meant maybe your app crashed, maybe it handled it gracefully and all that happened was the screen went black for a second. A driver issue on that same nvidia GPU in Linux means a kernel panic and the whole machine crashes, even things not running GPU workloads.

There are pros and cons each way about whether you bundle in the drivers into the kernel or have them live outside. Having it live in the kernel means if the vendor never bothers maintaining or opensourcing the driver you're just stuck on the old kernel. I've got a drawer full of computers which will never see a modern kernel and still keep all their functionality. A pile of e-waste because of the requirement to use that specific kernel the device shipped with, nothing else.

EDIT: Put it to sleep to write the comment, picked it up 20 minutes later, woke straight to the game without dropping a beat again.

> I would never, ever put my Windows laptop to sleep with an unsaved Excel sheet open. If it wakes up, there's a good chance that application is mysteriously restarted. I don't trust anything on Windows.

I would never, ever put any Linux laptop I've owned regardless of distro to sleep with any unsaved work at all. There's a good chance it just won't wake up at all, much less have some app restarted. I wouldn't say I don't trust anything on Linux, but generally not waking from sleep.

The Switch is a purpose-built device and is excellent at sleeping, I agree. SteamOS seems to be pretty good at it as well, but it's also hyper optimized with a massive tech company focusing on an extremely limited set of hardware which happens to include the Legion Go at the moment. We'll see if other systems work as smooth once it starts supporting more hardware. It's good there's more competition out there and it's great SteamOS is as great as it is.

But honestly I don't have any problems gaming on a Windows handheld especially after fixing this sleep driver issue on this specific device. I do agree it's clunkier than it needs to be in many ways and I hope Microsoft makes improvements like what they're talking about with that Xbox focused gaming handheld.

But I guess the future was already set.

Maybe it was spawning more threads than P cores, because it expected to be able to use all cores.

1. renaming all your process nodes to the next smaller size even though nothing changed

2. using TSMC process to ship products, when they already own a foundry

3. shipping multiple generations of products to consumers that just flat out destroy themselves, then blaming others

4. adding "efficiency" cores to inflate core counts

5. removing hyperthreading in the name of performance

6. introducing the "i9" series of processors, which are just the previous generation "i7" with a price premium added

7. Renaming all of your product lines to things like "9" instead of "i9" to obscure the absolutely absent generational improvements

8. shipping CPUs that support AVX512 and then disabling it after the product release

9. shipping an entire graphics product line with innovative new features, which do not actually work on launch

case in point: there are no fewer than 7 clock speeds listed for this CPU here on Intel's own page

https://www.intel.com/content/www/us/en/products/sku/241060/...

Which one is it? Why did they only list 7? Couldn't they have listed at least 23 more? Surely there are other clock speeds that are important. Do I have 8 cores, 16 cores, or 24? Can I use all 24? Are those cores the same? Are they even remotely comparable? Do they all support the same instruction set? Do I have 36 Megabytes of Intel smart cache, or is it 40 megabytes? Is this a 125 watt CPU or 250 watts? Does this processor do anything that is anyway different from a middle of the line CPU from nearly 8 years ago, that I can buy a fully working system from a recycler from for less than the cost of this CPU?

Now every mobile device, meaning any form of computing on the go, has multiple performance/low power CPU cores, a GPU, programble audio, NUMA, and maybe even a NPU.

No one has come close to solving the problem of optimizing software for multiple heterogeneous CPU's with differing micro-architectures when the scheduler is 'randomly' placing threads. There are various methods in linux/windows/etc which allow runtime selection of optimized paths, but they are all oriented around runtime selections (ex pick a foo variation based on X and keep it) made once, rather than on cpu/context switch.

This means that one either uses a generic target and takes the ~1.5-2.5x perf hit, or one optimizes for a single core type and ignores the perf on the other cores. This is probably at least partially why the gaming IPC numbers are so poor. The games are optimized for a much older device.

So a 1.5-2.5x perf difference is these days could be 5-10 years of performance uplifts being left on the table. Which is why AMD seems to be showing everyone a better path by simply using process optimizations and execution time optimization choices with the same zen cores. This gives them both area, and power optimized cores without having to do a lot of heavyweight scheduler/OS and application optimization. Especially for OS's like Linux which don't have strong foreground/background task signalling from a UI feeding the scheduler.

In other words heterogeneous SMP cores using differing micro-architectures will likely be replaced with more homogeneous looking cores that have better fine grained power and process optimizations. Ex, cores with even wider power/performance ranges/dynamism will win out over the nearly impossible task of adding yet another set of variables to schedulers which are already NP-hard, and adding even finer grained optimized path selection logic which will further damage branch prediction + cache locality the two problems already limiting CPU performance.

I think this isn't wholly correct. The comp sci part of things is pretty well figured out. You can do work-stealing parallelism to keep queues filled with decent latency, you can even dynamically adjust work distribution to thread performance (i.e. manual scheduling.) It's not trivial to use the best techniques for parallelism on heterogenous architecture, especially when it comes to adapting existing code bases that aren't fundamentally compatible with those techniques. Things get even more interesting as you take cache-locality, io, and library/driver interactions into consideration. However, I think it's more accurately described as an adoption problem than something that's unsolved. It took many years after their debut for homogenous multicore processors to be well supported across software for similar reasons. There are still games that are actively played which don't appreciably leverage multiple cores. (e.g. Starcraft 2 does some minimal offloading to a 2nd thread.)

AKA: I'm talking about the uplift one gets from say -march=native (or your arch of choice), FDO/PGO and various other optimization choices. Ex: Instruction selection for OoO cores. The compiler can know you only have to functional units capable of some operation with coreX, and your codes critpath is bottlnecked by those operations and can adjust the instruction mix to (mis)use some other functional units in parallel. Two units doing X, and one doing Y. Or just load to use latency, or avoidance of certain sequences, etc.

Those optimizations are tightly bound to a given core type. Sure modern OoO cores do a better job of keeping units busy, but its not uncommon to be working around some core deficiency by tweaking the compiler heuristics even now. Trolling through the gcc machine definitions:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i38...

So, when the CPU's are heterogeneous with differing optimization targets the code author ends up picking 'generic' optimization targets, and this decision by itself can frequently mean leaving a generation or two of performance behind vs the usual method of just building a handful of shared libraries/etc and picking one at runtime based on the cpu type.

Although, sure an application author can on some platforms hook a rescheduling notification, and then run a custom thread local jump table update to reconfigure which code paths are being run, or other non-standard operation. Or for that matter just set their affinity to a matching set of cores, but none of this is a core operation in any of the normal runtime/etc environments without considerable effort on the part of the application vendor.

Funny you would say that, because AMD X3D CPUs have cores with 3D Cache, and cores without, and massive scheduling problems because of this.

It just goes to show how hard scheduling actually is.

But also, you call it a 'massive' problem and its actually somewhat small in comparison to what can happen with vastly different core types in the same machine. Many of those cores also have quite large cache differences too.

I don't think (but could be wrong) that C++ has a platform independent way of doing this either. I'm not even sure if such an API is exposed from the Windows or linux kernel (though I'd imagine it is).

That to me is the bigger issue here. I can specify which core a thread should run on, but I can't specify what type of core it should run on.

> On platforms with heterogeneous processors, the QoS of a thread may restrict scheduling to a subset of processors, or indicate a preference for a particular class of processor.

https://learn.microsoft.com/en-us/windows/win32/procthread/q...

For starters: https://man7.org/linux/man-pages/man3/pthread_setschedparam....

None of the standard attributes (AFAIK) are directly "put me on a tiny core", but they frequently work hand in hand with those decisions. Lower your priority and the scheduler dumps you on some low clocked small core kinds of effects when its not busy. Or if you have machine knowledge just set your core affinity with pthread_setaffinity_np() which as the extension states is non-portable but can directly translate to "run me on a tiny core" if the right mask is provided.

At least in C/C++ most if not all modern platforms provide these kinds of controls and metadata and while the API might change a bit writing a couple versions of schedule_me_on_a_tiny_core() for each target platform is fairly trivial.

This just reads like “if they haven’t handled this specific case they’ve made no effort at all across the board” which seems extreme.

That'd be because this article is trying to analyze Intel's Lion Cove cores. The e-cores and issues caused by heterogeneous cores are therefore irrelevant, only the P-cores are Lion Cove.

By all means anything released in 2025 doesn't have that excuse - but I can't fault the authors of 15+ years old programs for not having a crystal ball and accounting for something which didn't exist at the time. Intel releasing something which behaves so poorly in that scenario is.... not really 100% fine in my eye. Maybe a big warning sticker on the box (performs poorly with pre-2024 software) would be justified. Thankfully workarounds exist.

P.S. At least I would have expected them to work more closely with OS vendors and ensure their schedulers mitigate the problem, but nope, doesn't look like they did.

Sometimes it doesn't happen Day 1 which is only a problem for the consumers that notice.

I also moved to AMD (5800X3D) due X3D alone being a massive improvement for simulations. Intel is still better in the laptop space and just outright more available (though I'm Mac-only for day-to-day laptop usage).

Afaik Windows is delegating most of scheduling work to "Intel Thread Director".

What makes you sound optimistic about part "how to schedule" ? Do you have any links I can follow?

With concepts such as "chromebook" (semi-merging with android phones), apple convergence between iPhone and iComputer chipset and code, Samsung DeX (run samsung phone as a desktop), in my opinion the endpoint is:

- Your phone is your desktop is your laptop. It may dock with a keyboard/monitor. This will happen when software kit is integrated between phone and computer (Microsoft has tried this in the past - too early), and the formfactor is sorted. Also a key gating item is phone CPUS matching laptop performance - Also some form of local AI will be present everywhere - Also, sadly, the way things our headed, such a system will be hardcore locked down if it inherits more from the phone ecosystem than the OS ecosystem

Especially in Europe where consoles were largely irrelevant during the 8 and 16 bit days.

The overall market doesn't give us enough resolution to determine the health of gaming PC sales IMO. There's too many other possible ways we get to that same number.

It used to be much easier to justify adding a dedicated GPU to the desktop's people where already getting, but when everyone is buying laptops that’s dying. As shown by end of generation mid range cards like the 4060 (2 years old, nothing newer) being relatively less common than they used to be on Steam.

#1 Laptop 4060 4.99%, #3 desktop 4060 4.41%. Overall gaming desktop PC’s are still more common than gaming laptops, but the trend is very much down. #2 is the 4 year old 3060.

Hows your post related to anything here?

“Games requiring desktop cases looking like a rainbow aquarium with top everything will become a niche, in today's mobile computing world”