> E-Cores are turned off in the BIOS, because setting affinity to P-Cores caused massive stuttering in Call of Duty.
I understand doing this for the purpose of specifically analyzing the P-core microarchitecture in isolation. However this does make the test less interesting for potential customers. I don't think many people would disable E-cores in BIOS if they bought this CPU, so for the purpose of deciding which CPU to buy, it would be more interesting to see results which factor in the potential software/scheduling issues which come from the E-core/P-core split.
This isn't a criticism, just an observation. Real-world gaming results for these CPUs would be worse than what these results show.
> I don't think many people would disable E-cores in BIOS if they bought this CPU, so for the purpose of deciding which CPU to buy, it would be more interesting to see results which factor in the potential software/scheduling issues which come from the E-core/P-core split.
Every mainstream review includes the E-cores. It’s not interesting to continue to repeat that testing.
The purpose of this article is an architectural exploration. Disabling the E-cores is a way to reveal that.
If you’re looking for simple gaming benchmarks to decide which CPU to buy, this isn’t the site for it. There are countless outlets for generic gaming reviews. This site examines architectural details.
I think many haven't yet grasped the future is heterogeneous computing, especially, when many desktops are actually laptops nowadays.
Software working poorly in such setup means no effort was made to actually make it perform well in first place.
Games requiring desktop cases looking like a rainbow aquarium with top everything will become a niche, in today's mobile computing world, and with diminishing sales and attention spans, maybe that isn't the way to keep studios going.
> Software working poorly in such setup means no effort was made to actually make it perform well in first place.
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 ;)
Laptops are PC gaming, the only ones declaring them dead are the console generation that never played 8 and 16 bit home computers.
For a game that gets yearly releases, I guess a decade would be long enough, given the existence of heterogeneous core programming across consoles and desktop systems.
Is windows even usable on laptops still? Between the waking from sleep to check notifications and the intensity of all the new background tasks it likely isn't pleasant.
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.
At some point you have to blame the driver model on Windows. People have been saying "it's the drivers" for 30 years.
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.
> At some point you have to blame the driver model on Windows.
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
While this is definitely true, we have to acknowledge Windows has some unique challenges in this space. Sleep pretty much never works correctly on Windows laptops. For me, suspend does. In addition, Windows does have background processes doing god knows what. 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.
> Sleep pretty much never works correctly on Windows laptops
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.
> Sleep has worked pretty much fine on the vast majority of the Windows computers I've owned/managed
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.
> There was that one Windows handheld recently that released a SteamOS version
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.
> 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.
As for monitors not being attached after sleep, I was mostly talking about macOS but I do get my comment isn't clear on that. It's an incredibly common issue.
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.
I just did a trial after the changes I made to my Legion Go running Windows the other day. Woke the system from sleep on my desk after a day, dropped a couple percent of battery. Started a game, played for half an hour. Pressed the power button to sleep, set it down for a few hours. Picked it back up and pressed the power button. PIN on the lock screen, and I'm back in the game as if nothing happened. Didn't lose 1% while sleeping during that break.
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.
That was very different, here the problem is the game's threads get scheduled on the weak E-cores and it doesn't like that for some reasons, with the PS3 that would have been impossible, SPEs had a different ISA, and didn't even have direct access to memory, the problem was developers had to write very different code for the SPEs to unlock most of the performance of the Cell.
You can replace "for some reasons" with it was scheduled on an inferior core that is used to inflate marketing metrics and should have never been on the silicon in the first place. The CPU in question is a Intel® Core™ Ultra 9 Processor 285K. No one buys this CPU for efficiency. In the absence of actual technical innovation, Intel has resorted to simply attempting to game the system with measures like
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
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?
When Cell came to be, heterogeneous computing was mostly a HPC thing, and having the compute units only programmable in Assembly (you could use C, but really not), didn't help.
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.
I did some programming for the Cell, and it definitely wasn't in assembly. It did require using intrinsics though, so I guess it was a little assembly-like.
I did mention C was supported, though if you really wanted to push them to the limit, and given the limited memory as well, Assembly was the way to go.
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.
> 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.
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.)
I'm not sure I understand what your trying to say here WRT to cpu microarch optimization with multiple cpu microarches in the machine. Maybe something about SMT/hyperthreading? But that doesn't appear to be what your saying either.
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:
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.
Yeah, sorry, everything you're saying is right. Compilers won't do the work for you. I just took issue with the wording about it being unsolved. If we can produce optimal binaries for a given process for multiple architectures we can also swap them as needed. I don't think any big new ideas need to come around, just work to implement ideas we have.
By the way, compilers can conceivably do "lowest common denominator" architecture optimization to get decent perf on heterogenous cores as a compromise, without leaning into every optimization for both core types.
> 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.
Funny you would say that, because AMD X3D CPUs have cores with 3D Cache, and cores without, and massive scheduling problems because of this.
Which is just caching/locality asymmetries, knowledge of which has been at least partially integrated into schedulers for a couple decades now.
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 think part of the problem is that from where I stand, there's no way to tell my programming language (java) "Hey, this thing doesn't need horsepower so prefer to schedule it on little cores." Or conversely "Hey, this thing is CPU sensitive, don't put it on a LITTLE core."
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.
Windows has an API for that, I don't think it's widely used though:
> 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.
POSIX threads, used by C/C++ and a lot of other language runtimes is somewhat platform independent and provides for affinity, priority and policy controls.
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.
Not “no effort to make sure it performs well in the first place”, that isn’t fair. Lots of effort probably went into it performing well, just this case isn’t handled yet and to be fair this only impacts some people currently and there is a chance to update it.
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.
Are you asking why the author of this article is disabling e-cores?
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.
You can still buy and build (I do) powerful gaming-capable systems that do not emit rainbow-puke or have transparent panels and other gimmicky stuff like that.
There's a giant pile of software - decades worth of it, literally - which was already written and released, much of it now unmaintained and/or closed source, where the effort you cite is not a possibility.
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.
Imagine going back when 12th gen was released and posting your post. Alas, nothing has improved in 5 generations of hardware that required complete PC rebuild each time since then. Buying intel for gaming is like a test for ignorance now. There might be a decade before any trust can be restored in the brand /imho.
Not sure what you're talking about, NT/Linux are well aware of the P/e cores and how to schedule among them for these past handful of generations.
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).
I am talking about gaming workloads being less efficient on particular E-core enabled CPUs. My point is that Day 1 has been generations ago and gaming workloads suffer the same as of that Day 1. Linked article does not mention running anything on Linux so not sure why to bring it up. Note that linked article sidestepped those issues by disabling E-cores.
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
People have been making the same argument for more than a decade now, meanwhile PC gaming has only kept growing. If that was the case, why hasn't it happened yet?
Every kid and teen I know wants one of those shiny gaming PCs. Much more than past decades thanks to all of their favorite streamers predominantly playing on gaming PCs. They have half an aisle of those PCs just at Costco. Seems out of touch to suggest this is a declining trend.
It’s arguing desktop gaming is dying not PC gaming. Q4 2024 shipped 13.6 million desktops (down 1.8%) vs 53.2 million laptops up (6.8%).
That trend of declining Desktops vs increasing laptops has been steady since 2010. There’s still plenty of desktops to justify major investments by gaming companies, but that’s not guaranteed long term.
That's just overall desktop and laptop sales though, right? So home multimedia desktop PCs could be falling off a cliff, business desktop PCs could be dropping, and gaming PCs could be growing a bit and the overall market of desktops could still be net down, right?
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.
You see a similar trend in gaming desktops vs gaming laptops, but that’s just a sideshow. People game on the hardware they have, gaming specific PC’s are a subset of the overall player base.
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.
That's a strange movement of a goal post, not to mention that using percentages conveniently hides whether PC Gaming as a whole is growing or shrinking.
Yep, I don't think chipsandcheese is trying to write a review of the CPU for practical purposes. Their content is more on technical microachitechture minutiae. In pretty much all of their articles they work to isolate performance characteristics of subsystems to show the differences that can be attributed to just the changes in that system gen-on-gen or between manufacturers.
It’s also a relatively “old” Call of Duty entry (2020-2021), in a series that famously ditched its older yearly entries quickly. The newer ones probably work fine with E-cores.
Is this a problem with Intel or with the OS scheduler? Haven't they had this kind of CPUs for a few years now, with this being touted as a reason to move from Win10 to 11?
But since we're on a technical forum where my initial comment's parent seems to argue this issue is Intel's fault, I think it's interesting to determine whether that's actually the case.
Of course, had Intel not released such a CPU, we wouldn't be having this conversation. But since they have released similar ones a few years ago now, is it still (only?) their fault?
The recommended actions are built around the assumption optimal gaming performance is the only market segment to please. Of course, efficiency cores were never about pleasing that segment anyways - gamers want fewer huge cores, not lots of big cores or tons of efficient cores. That Windows gaming is slightly imperfect due to scheduling difficulties will not stop AMD, Intel, ARM, etc from continuing to use different sized cores on non-uniform interconnects if it means larger changes in perf/watt and perf/cost for that price.
In practice this is more of a problem for gaming news site headlines than users anyways. For all but the biggest enthusiast the uplift from going to a new system is usually so much they'd not notice it could be a couple percentage points better or that one game is still a bit hitchy. It's us ultra-nerds that care about the 1% lows between different top end CPUs, and we tend to be quickly convinced the problem is Microsoft's to solve for us when the scheduling problem hits ARM, AMD, and Intel based Windows devices equally.
Although Intel’s configurations are unhelpful to say the least: it’s hard to make good scheduling decisions when Intel sells a 2P, 8E, 2LE as a 12 cores to the user.
Normally "let me google it for you" is impolite on this site but I hope not in this case. Here we go:
"Intel Thread Director leverages machine learning to make intelligent decisions about how to utilize the different types of cores in a hybrid processor, leading to better overall performance and power efficiency."
Feel free to unsee it and ban me.
Disclaimer: I work in gamedev on engine and performance.
I wonder if there's also something to do with how the window scheduler (or allocator, or driver interaction, or some system component—I just guessed the scheduler because it seems like the most likely thing to be different enough to drive this sort of phenomenon) approaches the task. I notice remarkably smoother gameplay with the same games under wine—even, confusingly, games developed in house at Microsoft like Flight Simulator—with the same hardware.
Tell that to AMDs bulldozer. There is something to be said for considering theoretical performance, but one can't ignore how hardware works in practice, now.
To see what that means in practice, in my multi generational meta benchmark the 285K lands currently only on rank 12, behind the top Intel processors from the last two generations (i7-13700K and 14700K plus the respective i9) and several AMD processors. https://www.pc-kombo.com/us/benchmark/games/cpu. The 3D cache just helps a lot in games, but the loss against the own predecessor must hurt even more.
I see how that can be misleading. It's globally not a percentage based score.
The benchmark is creating a global order based on which one is faster, including indirect comparisons. But that only takes care of the position, not the rating. That one is based on the percentage between direct neighbor iff there is a direct comparison in the benchmark data, otherwise it's a small .1 increment. So many small percentage increases that don't necessarily match the direct comparion between parts that are not neighbors. Sometimes that works great, sometimes not.
Here the example looks a bit pathological, that difference is further off than I expected when introducing the calculation recently. For the 12700K and 13700K, the direct comparison sees the 12700K at 85% of the 13700k:
So yeah, sorry, that part is misleading right now. I'll check the calculation.
But the ingested individual benchmark numbers and the ranking, so the position, is very solid I'd say. With the caveat that ranking position can change with more data.
For gaming, those CPUs were a sidegrade at best. To be honest, it wouldn't have been a big issue, especially for folks upgrading from way older hardware, if only their pricing wasn't so out of line with the value that they provide (look at their GPUs, at least there the MSRP makes the hardware good value).
So, for one in other software the new processors do better. The 285K beats the i9-14900KS by a bit in my app benchmark collection (which is less extensive, but still). And second yes, according to https://www.computerbase.de/artikel/prozessoren/intel-core-u... for example they are less extreme in their energy usage and more efficient in general, albeit not more efficient than the AMD processors.
> I seem to remember you'd need dedicated industrial cooling for the 14700k.
Those CPUs run hot, but it got exaggerated a lot online. It’s not hard to handle their heat with a good air cooler (even some of the $50 units like the Peerless Assassin) or a run of the mill closed loop water cooler.
There are a lot of old notions in the gaming community that you need to keep CPUs under arbitrary temperature thresholds or that any throttling is bad. Modern CPUs and GPUs run themselves deep into the performance curves and slight throttling is barely noticeable.
Hm, to keep in mind though that what the gaming community always claimed actually did happen with those processors - they disintegrated because of too much voltage (and probably heat). https://www.pcgamer.com/hardware/processors/intel-cpu-crashe.... So the "run themselves deep into the performance curves" part of these Intel processors was a disaster.
If you want people to take your benchmark seriously, you'd need to provide a very great deal more information on how those numbers are generated. "It's complicated, just trust me" isn't a good enough explanation.
If you want people to listen, you need to have a link where you explain what hardware you're using, what settings you're using, what apps/games you're running, what metrics you're using and how you compute your Magical Number.
My already high level of sceptism is compounded by some scarcely-believable results, such as that according to your testing the i9-14900K and i9-13900K have essentially identical performance. Other, more reputable and established sources do not agree with you (to put it mildly).
Hey, I do try to make the site as transparent as possible - but admit that the site does not make it obvious. For such a doubt, go into the comparison of the two (https://www.pc-kombo.com/us/benchmark/games/cpu/compare?ids%...) where all benchmarks used that the two processors share are listed. The benchmark bars are clickable and go to the source.
It does get really complicated to address something like that when all comparisons are indirect. Thankfully, that's not the case here.
Seeing that the Lion Cove L3 cache takes ~83 cycles while the previous generation was only ~68 cycles explains why Lion Cove is an utter dud of a CPU for gaming and why it loses to the Raptor Cove in so many gaming benchmarks.
Meanwhile, the Zen 5 is only 47 cycles, and if you get the X3D variant, you get a TON of that L3 cache, which just turbo-charges games.
How did Intel allow such a major performance regression in their L3 cache?
Such articles are very interesting for many people, because nowadays all CPU vendors are under-documenting their products.
Most people do not have enough time or knowledge (or money to buy CPU samples that may prove to be not useful) to run extensive sets of benchmarks to discover how the CPUs really work, so they appreciate when others do this and publish their results.
Besides learning useful details about the strengths and weaknesses of the latest Intel big core, which may help in the optimization of a program or in assessing the suitability of an Intel CPU for a certain application, there is not much to comment about it.
It is an interesting but particularly non-actionable analysis: only a handful of engineers at Intel are in a position to design an improved Lion Cove, while the main takeaway for the game programmers who care about game workload performance is that nothing performs too badly and therefore general performance improvement techniques like accessing less memory are a good fit for this processor.
they still cannot reach power figures they had in the last, 3? generations. 13 and 14 series, which made these figures by literally burning themselves to the point of degradation.
intel has no competition to amd in the gaming segment right now. they control both the low energy efficiency market and the high performance one.
While Lunar Lake has excellent energy efficiency and AMD does not really have any CPU designed for low power levels, Lunar Lake had also a very ugly hardware bug (sporadic failure of MWAIT to detect the waking event).
This bug has disqualified Lunar Lake for me, and I really do not understand how such a major bug has not been discovered before the product launch (the bug has been discovered when in many computers running Linux the keyboard or the mouse did not function properly, because their events were not always reported to the operating system; there are simple workarounds for the bug, but not using MONITOR/MWAIT eliminates one of the few advantages that Intel/AMD CPUs have over Arm-based CPUs, so I do not consider this as an acceptable solution).
Fantastic article -as always. Regarding the top-down analysis: I was a bit surprised to see that in ~1/5 of the cases the pipeline stalls b/c the pipeline is Frontend Bound. Can that be? Similarly, why is Frontend Bandwidth a subgroup of Frontend Bound? Shouldn't one micro-op be enough?
Take front end bound with a grain of salt. Frequently I find a backend backpressure reason for it, e.g. long-tail memory loads needed for a conditional branch or atomic. There are limitations to sampling methods and top down analysis, consider it a start point to understanding the potential bottlenecks, not the final word.
There's no single good way, but yes as you said, logical deduction based on the surrounding instructions and their hardware counters is a way to do it. Instruction B might be collecting a ton of hardware counted cycles, but it could be because instruction A it depends on is slow. Sometimes, those dependencies are even implicit, since x86 is in-order commit some instructions like lock/atomics have implicit and dynamic dependencies based on what is in the reorder buffer at the time.
To give a concrete example I encountered analysing a GC: traversing the object graph in a loop means calculating the address of an object, loading that object, doing some work on it and then grabbing the bits to calculate the children to visit next. This creates a long brittle chain of data-dependent conditionals, depending on a calculation that eventually came from a much earlier load. That conditional branch might be 30/70 taken/untaken, so the branch predictor often does not speculate, reducing the ILP and making it harder to hide the load's latencies. Now, dear Watson, would you say the blame is to the front end? There are no stalls when all the loads go to fast cache, only when there is the occasional remote LLC hit, DRAM hit or god forbid cross-NUMA hit. What if I tell you that there's an atomic operation to mark the object as visited, which is fast in itself but can only be issued when all prior loads have completed and stops from newer instructions to be issued while it hasn't been committed.
You need to look at a whole bunch of surrounding instructions and a variety of hardware counters to start forming a picture. Insert Always Sunny in Philadelphia meme with the red wire crime board here.
Another thing you could do if you want to understand more of the details is open this article with an LLM and ask it questions. Have it explain unfamiliar terms and comparisons to you
I'm pretty sure memory is still the main bottleneck in the vast majority of operations, and why the X3D is such a monster with so much L3 cache. There's almost nothing that doesn't benefit from having twice the memory bandwidth.
> Lion Cove suffers harder with backend memory latency, but far less from frontend latency. Part of this can be explained by Zen 4’s stronger data-side memory subsystem. The AMD Ryzen 9 7950X3D I previously tested on has 96 MB of L3 cache on the first die, and has lower L3 latency than Lion Cove in Intel’s Arrow Lake platform. Beyond L3, AMD achieves better load-to-use latency even with slower DDR5-5600 36-36-36-89 memory. Intel’s interconnect became more complex when they shifted to a chiplet setup, and there’s clearly some work to be done.
They only compared three games of roughly the same genre in terms of mechanics which is not exactly a representative benchmark either, even for games. The average shooter with a fixed map and say, Minecraft, have vastly different memory access demands.
They're referring to the ordinary DDR5-on-a-stick Ryzen implementation, not the LPDDR5X Ryzen AI implementation.
ETA: The only non-laptop results I have seen for the Ryzen AI place it worse than the 9950X, which has 2-channel plain old DDR5. The 4-channel LPDDR5X only wins when it can exploit the bandwidth and hide the latency, such as physics simulations. But for most applications the 9950X beats it. Hence my original point now well upthread: still waiting to see if the Strix Halo architecture is good for anything.
Strix Halo has a big GPU (for a laptop chip). GPUs love memory bandwidth and can tolerate latency, so... Strix Halo should be (and is) good at graphics and GPGPU.
Apple's M-series of chips make use of more than two memory channels. I don't think there is evidence that it is actually beneficial for anything but marketing though.
> E-Cores are turned off in the BIOS, because setting affinity to P-Cores caused massive stuttering in Call of Duty.
I understand doing this for the purpose of specifically analyzing the P-core microarchitecture in isolation. However this does make the test less interesting for potential customers. I don't think many people would disable E-cores in BIOS if they bought this CPU, so for the purpose of deciding which CPU to buy, it would be more interesting to see results which factor in the potential software/scheduling issues which come from the E-core/P-core split.
This isn't a criticism, just an observation. Real-world gaming results for these CPUs would be worse than what these results show.
> I don't think many people would disable E-cores in BIOS if they bought this CPU, so for the purpose of deciding which CPU to buy, it would be more interesting to see results which factor in the potential software/scheduling issues which come from the E-core/P-core split.
Every mainstream review includes the E-cores. It’s not interesting to continue to repeat that testing.
The purpose of this article is an architectural exploration. Disabling the E-cores is a way to reveal that.
If you’re looking for simple gaming benchmarks to decide which CPU to buy, this isn’t the site for it. There are countless outlets for generic gaming reviews. This site examines architectural details.
I think many haven't yet grasped the future is heterogeneous computing, especially, when many desktops are actually laptops nowadays.
Software working poorly in such setup means no effort was made to actually make it perform well in first place.
Games requiring desktop cases looking like a rainbow aquarium with top everything will become a niche, in today's mobile computing world, and with diminishing sales and attention spans, maybe that isn't the way to keep studios going.
> Software working poorly in such setup means no effort was made to actually make it perform well in first place.
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 ;)
Laptops are PC gaming, the only ones declaring them dead are the console generation that never played 8 and 16 bit home computers.
For a game that gets yearly releases, I guess a decade would be long enough, given the existence of heterogeneous core programming across consoles and desktop systems.
Is windows even usable on laptops still? Between the waking from sleep to check notifications and the intensity of all the new background tasks it likely isn't pleasant.
> Is windows even usable on laptops still?
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.
At some point you have to blame the driver model on Windows. People have been saying "it's the drivers" for 30 years.
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.
> At some point you have to blame the driver model on Windows.
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?
https://learn.microsoft.com/en-us/answers/questions/2318281/...
> 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
Posted by: Anonymous
Yeah, real official documentation there.
Got anything more real in terms of documentation other than a forum post by anonymous?
S1 S2 S3 S4 sleep modes and what happened to the most useful of them ;)
While this is definitely true, we have to acknowledge Windows has some unique challenges in this space. Sleep pretty much never works correctly on Windows laptops. For me, suspend does. In addition, Windows does have background processes doing god knows what. 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.
> Sleep pretty much never works correctly on Windows laptops
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.
> Sleep has worked pretty much fine on the vast majority of the Windows computers I've owned/managed
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.
> There was that one Windows handheld recently that released a SteamOS version
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.
> 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.
As for monitors not being attached after sleep, I was mostly talking about macOS but I do get my comment isn't clear on that. It's an incredibly common issue.
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.
I just did a trial after the changes I made to my Legion Go running Windows the other day. Woke the system from sleep on my desk after a day, dropped a couple percent of battery. Started a game, played for half an hour. Pressed the power button to sleep, set it down for a few hours. Picked it back up and pressed the power button. PIN on the lock screen, and I'm back in the game as if nothing happened. Didn't lose 1% while sleeping during that break.
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.
Which is funny because the pushback the PS3 got from developers was too much. Maybe it was "too heterogeneous"
But I guess the future was already set.
That was very different, here the problem is the game's threads get scheduled on the weak E-cores and it doesn't like that for some reasons, with the PS3 that would have been impossible, SPEs had a different ISA, and didn't even have direct access to memory, the problem was developers had to write very different code for the SPEs to unlock most of the performance of the Cell.
Even more weirdly: affinity was set to the P cores, so it wasn't being scheduled on E cores at all.
Maybe it was spawning more threads than P cores, because it expected to be able to use all cores.
You can replace "for some reasons" with it was scheduled on an inferior core that is used to inflate marketing metrics and should have never been on the silicon in the first place. The CPU in question is a Intel® Core™ Ultra 9 Processor 285K. No one buys this CPU for efficiency. In the absence of actual technical innovation, Intel has resorted to simply attempting to game the system with measures like
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?
When Cell came to be, heterogeneous computing was mostly a HPC thing, and having the compute units only programmable in Assembly (you could use C, but really not), didn't help.
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.
I did some programming for the Cell, and it definitely wasn't in assembly. It did require using intrinsics though, so I guess it was a little assembly-like.
I did mention C was supported, though if you really wanted to push them to the limit, and given the limited memory as well, Assembly was the way to go.
Fair. At the time I packed the necessary understanding to know of the GCC-emitted object code was significantly suboptimal.
s/packed/lacked/
Is it?
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.
> 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.
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.)
I'm not sure I understand what your trying to say here WRT to cpu microarch optimization with multiple cpu microarches in the machine. Maybe something about SMT/hyperthreading? But that doesn't appear to be what your saying either.
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.
Yeah, sorry, everything you're saying is right. Compilers won't do the work for you. I just took issue with the wording about it being unsolved. If we can produce optimal binaries for a given process for multiple architectures we can also swap them as needed. I don't think any big new ideas need to come around, just work to implement ideas we have.
By the way, compilers can conceivably do "lowest common denominator" architecture optimization to get decent perf on heterogenous cores as a compromise, without leaning into every optimization for both core types.
> 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.
Funny you would say that, because AMD X3D CPUs have cores with 3D Cache, and cores without, and massive scheduling problems because of this.
Which is just caching/locality asymmetries, knowledge of which has been at least partially integrated into schedulers for a couple decades now.
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 think part of the problem is that from where I stand, there's no way to tell my programming language (java) "Hey, this thing doesn't need horsepower so prefer to schedule it on little cores." Or conversely "Hey, this thing is CPU sensitive, don't put it on a LITTLE core."
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.
Windows has an API for that, I don't think it's widely used though:
> 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...
POSIX threads, used by C/C++ and a lot of other language runtimes is somewhat platform independent and provides for affinity, priority and policy controls.
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.
Not “no effort to make sure it performs well in the first place”, that isn’t fair. Lots of effort probably went into it performing well, just this case isn’t handled yet and to be fair this only impacts some people currently and there is a chance to update it.
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.
Then why taking the effort to look better that it actually is?
Are you asking why the author of this article is disabling e-cores?
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.
Ok I’m lost
You can still buy and build (I do) powerful gaming-capable systems that do not emit rainbow-puke or have transparent panels and other gimmicky stuff like that.
There's a giant pile of software - decades worth of it, literally - which was already written and released, much of it now unmaintained and/or closed source, where the effort you cite is not a possibility.
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.
AMD and Intel do work with Microsoft (and I'm sure provide code to the Linux scheduler) to optimize the NT scheduler appropriately.
Sometimes it doesn't happen Day 1 which is only a problem for the consumers that notice.
Imagine going back when 12th gen was released and posting your post. Alas, nothing has improved in 5 generations of hardware that required complete PC rebuild each time since then. Buying intel for gaming is like a test for ignorance now. There might be a decade before any trust can be restored in the brand /imho.
Not sure what you're talking about, NT/Linux are well aware of the P/e cores and how to schedule among them for these past handful of generations.
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).
I am talking about gaming workloads being less efficient on particular E-core enabled CPUs. My point is that Day 1 has been generations ago and gaming workloads suffer the same as of that Day 1. Linked article does not mention running anything on Linux so not sure why to bring it up. Note that linked article sidestepped those issues by disabling E-cores.
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?
>desktops are actually laptops nowadays.
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
People have been making the same argument for more than a decade now, meanwhile PC gaming has only kept growing. If that was the case, why hasn't it happened yet?
Every kid and teen I know wants one of those shiny gaming PCs. Much more than past decades thanks to all of their favorite streamers predominantly playing on gaming PCs. They have half an aisle of those PCs just at Costco. Seems out of touch to suggest this is a declining trend.
PC gaming has been growing since MS-DOS 3.3, when I was playing Defender of the Crown, in case people haven't been paying attention.
Especially in Europe where consoles were largely irrelevant during the 8 and 16 bit days.
It’s arguing desktop gaming is dying not PC gaming. Q4 2024 shipped 13.6 million desktops (down 1.8%) vs 53.2 million laptops up (6.8%).
That trend of declining Desktops vs increasing laptops has been steady since 2010. There’s still plenty of desktops to justify major investments by gaming companies, but that’s not guaranteed long term.
That's just overall desktop and laptop sales though, right? So home multimedia desktop PCs could be falling off a cliff, business desktop PCs could be dropping, and gaming PCs could be growing a bit and the overall market of desktops could still be net down, right?
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.
You see a similar trend in gaming desktops vs gaming laptops, but that’s just a sideshow. People game on the hardware they have, gaming specific PC’s are a subset of the overall player base.
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.
That's a strange movement of a goal post, not to mention that using percentages conveniently hides whether PC Gaming as a whole is growing or shrinking.
Hows your post related to anything here?
What moving the goalposts? They specifically talked about gaming desktops as a form factor which needs developer support.
“Games requiring desktop cases looking like a rainbow aquarium with top everything will become a niche, in today's mobile computing world”
Yep, I don't think chipsandcheese is trying to write a review of the CPU for practical purposes. Their content is more on technical microachitechture minutiae. In pretty much all of their articles they work to isolate performance characteristics of subsystems to show the differences that can be attributed to just the changes in that system gen-on-gen or between manufacturers.
It’s also a relatively “old” Call of Duty entry (2020-2021), in a series that famously ditched its older yearly entries quickly. The newer ones probably work fine with E-cores.
Yeah intel either needs to ensure much better day 1 support for E / P core split or drop it entirely.
People see them as an active negative right now rather than how intel pitches them
Is this a problem with Intel or with the OS scheduler? Haven't they had this kind of CPUs for a few years now, with this being touted as a reason to move from Win10 to 11?
It doesn't matter to the public's perception.
Right, it certainly doesn't.
But since we're on a technical forum where my initial comment's parent seems to argue this issue is Intel's fault, I think it's interesting to determine whether that's actually the case.
Of course, had Intel not released such a CPU, we wouldn't be having this conversation. But since they have released similar ones a few years ago now, is it still (only?) their fault?
OS scheduler is responsible; AMD/Intel work with Microsoft on the NT scheduler and likely contribute code on the Linux scheduler.
The recommended actions are built around the assumption optimal gaming performance is the only market segment to please. Of course, efficiency cores were never about pleasing that segment anyways - gamers want fewer huge cores, not lots of big cores or tons of efficient cores. That Windows gaming is slightly imperfect due to scheduling difficulties will not stop AMD, Intel, ARM, etc from continuing to use different sized cores on non-uniform interconnects if it means larger changes in perf/watt and perf/cost for that price.
In practice this is more of a problem for gaming news site headlines than users anyways. For all but the biggest enthusiast the uplift from going to a new system is usually so much they'd not notice it could be a couple percentage points better or that one game is still a bit hitchy. It's us ultra-nerds that care about the 1% lows between different top end CPUs, and we tend to be quickly convinced the problem is Microsoft's to solve for us when the scheduling problem hits ARM, AMD, and Intel based Windows devices equally.
Scheduling is the OS’s decision not the CPU’s.
Although Intel’s configurations are unhelpful to say the least: it’s hard to make good scheduling decisions when Intel sells a 2P, 8E, 2LE as a 12 cores to the user.
Normally "let me google it for you" is impolite on this site but I hope not in this case. Here we go:
"Intel Thread Director leverages machine learning to make intelligent decisions about how to utilize the different types of cores in a hybrid processor, leading to better overall performance and power efficiency."
Feel free to unsee it and ban me.
Disclaimer: I work in gamedev on engine and performance.
It is the OS fault as you say but consumers don't care who's fault it is only that it's broken
I wonder if there's also something to do with how the window scheduler (or allocator, or driver interaction, or some system component—I just guessed the scheduler because it seems like the most likely thing to be different enough to drive this sort of phenomenon) approaches the task. I notice remarkably smoother gameplay with the same games under wine—even, confusingly, games developed in house at Microsoft like Flight Simulator—with the same hardware.
> Real-world gaming results for these CPUs would be worse than what these results show.
That's mostly an application and/or OS issue, not really a CPU one.
Tell that to AMDs bulldozer. There is something to be said for considering theoretical performance, but one can't ignore how hardware works in practice, now.
It’s a problem of compatibility of those games, not an issue with the processor. The kind of thing a game or windows update solves.
Old games won't get updates. That is why there are multiple separate tools that try to force the situation. e.g. Process Lasso
Frustrated with this in the Linux world too - trying to get proxmox to play nicely with P/E is a nightmare. The OS scheduler side of things is a PITA
Pretty sure the mainstream gaming advice is to turn off E-Cores so the vast majority of actual gamers would be doing just that.
To see what that means in practice, in my multi generational meta benchmark the 285K lands currently only on rank 12, behind the top Intel processors from the last two generations (i7-13700K and 14700K plus the respective i9) and several AMD processors. https://www.pc-kombo.com/us/benchmark/games/cpu. The 3D cache just helps a lot in games, but the loss against the own predecessor must hurt even more.
Is your benchmark trustworthy?
I see strange discrepancy: my "old" i7-12700K vs i7-13700K:
Games: 170 vs 270 Software: 271 vs 1875 (!!!)
I can believe into 170 vs 270 (though, these two CPUs are not so different!) but 7x difference in software!? Is it believable?
I see how that can be misleading. It's globally not a percentage based score.
The benchmark is creating a global order based on which one is faster, including indirect comparisons. But that only takes care of the position, not the rating. That one is based on the percentage between direct neighbor iff there is a direct comparison in the benchmark data, otherwise it's a small .1 increment. So many small percentage increases that don't necessarily match the direct comparion between parts that are not neighbors. Sometimes that works great, sometimes not.
Here the example looks a bit pathological, that difference is further off than I expected when introducing the calculation recently. For the 12700K and 13700K, the direct comparison sees the 12700K at 85% of the 13700k:
https://www.pc-kombo.com/us/benchmark/games/cpu/compare?ids%...
For apps it's 79%:
https://www.pc-kombo.com/us/benchmark/apps/cpu/compare?ids[]...
So yeah, sorry, that part is misleading right now. I'll check the calculation.
But the ingested individual benchmark numbers and the ranking, so the position, is very solid I'd say. With the caveat that ranking position can change with more data.
I found a bug in the score calculation that inflated the score, this case is closer now.
I don't fully follow this, so what has been gained with the new models?
I seem to remember you'd need dedicated industrial cooling for the 14700k. Does the new model at least pump much less power?
> I don't fully follow this, so what has been gained with the new models?
There were power efficiency gains, as well as nice productivity improvements for some workloads: https://www.youtube.com/watch?v=vjPXOurg0nU
For gaming, those CPUs were a sidegrade at best. To be honest, it wouldn't have been a big issue, especially for folks upgrading from way older hardware, if only their pricing wasn't so out of line with the value that they provide (look at their GPUs, at least there the MSRP makes the hardware good value).
So, for one in other software the new processors do better. The 285K beats the i9-14900KS by a bit in my app benchmark collection (which is less extensive, but still). And second yes, according to https://www.computerbase.de/artikel/prozessoren/intel-core-u... for example they are less extreme in their energy usage and more efficient in general, albeit not more efficient than the AMD processors.
But it is a valid question.
> I seem to remember you'd need dedicated industrial cooling for the 14700k.
Those CPUs run hot, but it got exaggerated a lot online. It’s not hard to handle their heat with a good air cooler (even some of the $50 units like the Peerless Assassin) or a run of the mill closed loop water cooler.
There are a lot of old notions in the gaming community that you need to keep CPUs under arbitrary temperature thresholds or that any throttling is bad. Modern CPUs and GPUs run themselves deep into the performance curves and slight throttling is barely noticeable.
Hm, to keep in mind though that what the gaming community always claimed actually did happen with those processors - they disintegrated because of too much voltage (and probably heat). https://www.pcgamer.com/hardware/processors/intel-cpu-crashe.... So the "run themselves deep into the performance curves" part of these Intel processors was a disaster.
They were cooking themselves at idle too (see microcode 12F) so it's not clear heat/throttling is relevant
If you want people to take your benchmark seriously, you'd need to provide a very great deal more information on how those numbers are generated. "It's complicated, just trust me" isn't a good enough explanation.
If you want people to listen, you need to have a link where you explain what hardware you're using, what settings you're using, what apps/games you're running, what metrics you're using and how you compute your Magical Number.
My already high level of sceptism is compounded by some scarcely-believable results, such as that according to your testing the i9-14900K and i9-13900K have essentially identical performance. Other, more reputable and established sources do not agree with you (to put it mildly).
Hey, I do try to make the site as transparent as possible - but admit that the site does not make it obvious. For such a doubt, go into the comparison of the two (https://www.pc-kombo.com/us/benchmark/games/cpu/compare?ids%...) where all benchmarks used that the two processors share are listed. The benchmark bars are clickable and go to the source.
It does get really complicated to address something like that when all comparisons are indirect. Thankfully, that's not the case here.
The 13900K and 14900K in games really have been that close, see https://www.computerbase.de/artikel/prozessoren/intel-core-i... for an example, where the two have a 2% FPS difference.
Seeing that the Lion Cove L3 cache takes ~83 cycles while the previous generation was only ~68 cycles explains why Lion Cove is an utter dud of a CPU for gaming and why it loses to the Raptor Cove in so many gaming benchmarks.
Meanwhile, the Zen 5 is only 47 cycles, and if you get the X3D variant, you get a TON of that L3 cache, which just turbo-charges games.
How did Intel allow such a major performance regression in their L3 cache?
122 points and no comments? Is this being botted or something?
Such articles are very interesting for many people, because nowadays all CPU vendors are under-documenting their products.
Most people do not have enough time or knowledge (or money to buy CPU samples that may prove to be not useful) to run extensive sets of benchmarks to discover how the CPUs really work, so they appreciate when others do this and publish their results.
Besides learning useful details about the strengths and weaknesses of the latest Intel big core, which may help in the optimization of a program or in assessing the suitability of an Intel CPU for a certain application, there is not much to comment about it.
It is an interesting but particularly non-actionable analysis: only a handful of engineers at Intel are in a position to design an improved Lion Cove, while the main takeaway for the game programmers who care about game workload performance is that nothing performs too badly and therefore general performance improvement techniques like accessing less memory are a good fit for this processor.
>122 points and no comments?
Better no comments than having to trod through the typical FUD or off topic rants that tend to plague Intel and Microsoft topics.
exactly. I'm very happy to notice there are no 'x86 bad arm good' comments here as of now. a welcome change.
also - or maybe, first and foremost - it's just a very good article.
it's a very good article.
Could be. Usually it means the subject is too advanced for the average HN user yet something that they are interested in.
Substack.
I mean what is there to comment. Intel botched another product release. It is just a sad state of affairs.
How so?
Not that I disbelieve, I just wasn't especially picking that up from the article.
they still cannot reach power figures they had in the last, 3? generations. 13 and 14 series, which made these figures by literally burning themselves to the point of degradation.
intel has no competition to amd in the gaming segment right now. they control both the low energy efficiency market and the high performance one.
Do they? I thought Lunar Lake was an incredibly good efficiency generation.
While Lunar Lake has excellent energy efficiency and AMD does not really have any CPU designed for low power levels, Lunar Lake had also a very ugly hardware bug (sporadic failure of MWAIT to detect the waking event).
This bug has disqualified Lunar Lake for me, and I really do not understand how such a major bug has not been discovered before the product launch (the bug has been discovered when in many computers running Linux the keyboard or the mouse did not function properly, because their events were not always reported to the operating system; there are simple workarounds for the bug, but not using MONITOR/MWAIT eliminates one of the few advantages that Intel/AMD CPUs have over Arm-based CPUs, so I do not consider this as an acceptable solution).
It is
Fantastic article -as always. Regarding the top-down analysis: I was a bit surprised to see that in ~1/5 of the cases the pipeline stalls b/c the pipeline is Frontend Bound. Can that be? Similarly, why is Frontend Bandwidth a subgroup of Frontend Bound? Shouldn't one micro-op be enough?
Take front end bound with a grain of salt. Frequently I find a backend backpressure reason for it, e.g. long-tail memory loads needed for a conditional branch or atomic. There are limitations to sampling methods and top down analysis, consider it a start point to understanding the potential bottlenecks, not the final word.
Interesting. You realize this by identifying the offending assembly instructions and then see that one operands comes from memory?
There's no single good way, but yes as you said, logical deduction based on the surrounding instructions and their hardware counters is a way to do it. Instruction B might be collecting a ton of hardware counted cycles, but it could be because instruction A it depends on is slow. Sometimes, those dependencies are even implicit, since x86 is in-order commit some instructions like lock/atomics have implicit and dynamic dependencies based on what is in the reorder buffer at the time.
To give a concrete example I encountered analysing a GC: traversing the object graph in a loop means calculating the address of an object, loading that object, doing some work on it and then grabbing the bits to calculate the children to visit next. This creates a long brittle chain of data-dependent conditionals, depending on a calculation that eventually came from a much earlier load. That conditional branch might be 30/70 taken/untaken, so the branch predictor often does not speculate, reducing the ILP and making it harder to hide the load's latencies. Now, dear Watson, would you say the blame is to the front end? There are no stalls when all the loads go to fast cache, only when there is the occasional remote LLC hit, DRAM hit or god forbid cross-NUMA hit. What if I tell you that there's an atomic operation to mark the object as visited, which is fast in itself but can only be issued when all prior loads have completed and stops from newer instructions to be issued while it hasn't been committed.
You need to look at a whole bunch of surrounding instructions and a variety of hardware counters to start forming a picture. Insert Always Sunny in Philadelphia meme with the red wire crime board here.
I suggests using a Xeon w7 2595X so that you have 26P cores and 0E cores
I would like to understand more of the article, which book should I read?
https://archive.org/details/computerarchitectureaquantitativ...
That's more of a graduate level book. If you would like a book by the same author, that is lighter in content but much more approachable, I recommend this version: https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/books/H...
And don't forget to look at the online appendices on the MK website. They are also all very good.
Another thing you could do if you want to understand more of the details is open this article with an LLM and ask it questions. Have it explain unfamiliar terms and comparisons to you
Say, is there any talk about Intel working on an AMD Strix Halo competitor, i.e. quad channel LPDDR5X in the consumer section?
I am still waiting on evidence that memory architecture helps anyone.
I'm pretty sure memory is still the main bottleneck in the vast majority of operations, and why the X3D is such a monster with so much L3 cache. There's almost nothing that doesn't benefit from having twice the memory bandwidth.
Did you read the article?
The article literally says this very thing?
> Lion Cove suffers harder with backend memory latency, but far less from frontend latency. Part of this can be explained by Zen 4’s stronger data-side memory subsystem. The AMD Ryzen 9 7950X3D I previously tested on has 96 MB of L3 cache on the first die, and has lower L3 latency than Lion Cove in Intel’s Arrow Lake platform. Beyond L3, AMD achieves better load-to-use latency even with slower DDR5-5600 36-36-36-89 memory. Intel’s interconnect became more complex when they shifted to a chiplet setup, and there’s clearly some work to be done.
They only compared three games of roughly the same genre in terms of mechanics which is not exactly a representative benchmark either, even for games. The average shooter with a fixed map and say, Minecraft, have vastly different memory access demands.
Yeah, latency. Strix has higher bandwidth but it pays for it in higher (i.e. worse) latency.
They literally say AMD gets better latency on top of better bandwidth, are we reading the same sentences? Better = lower I would expect.
They're referring to the ordinary DDR5-on-a-stick Ryzen implementation, not the LPDDR5X Ryzen AI implementation.
ETA: The only non-laptop results I have seen for the Ryzen AI place it worse than the 9950X, which has 2-channel plain old DDR5. The 4-channel LPDDR5X only wins when it can exploit the bandwidth and hide the latency, such as physics simulations. But for most applications the 9950X beats it. Hence my original point now well upthread: still waiting to see if the Strix Halo architecture is good for anything.
Strix Halo has a big GPU (for a laptop chip). GPUs love memory bandwidth and can tolerate latency, so... Strix Halo should be (and is) good at graphics and GPGPU.
Apple's M-series of chips make use of more than two memory channels. I don't think there is evidence that it is actually beneficial for anything but marketing though.
Another article with some original slides from Intel. https://www.hwcooling.net/en/intels-new-p-core-lion-cove-is-...