[HN Gopher] Intel's Lion Cove P-Core and Gaming Workloads
___________________________________________________________________
Intel's Lion Cove P-Core and Gaming Workloads
Author : zdw
Score : 245 points
Date : 2025-07-06 22:27 UTC (1 days ago)
(HTM) web link (chipsandcheese.com)
(TXT) w3m dump (chipsandcheese.com)
| samrus wrote:
| 122 points and no comments? Is this being botted or something?
| PhilipRoman wrote:
| Could be. Usually it means the subject is too advanced for the
| average HN user yet something that they are interested in.
| adrian_b wrote:
| 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.
| HelloNurse wrote:
| 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.
| whatever10 wrote:
| I mean what is there to comment. Intel botched another product
| release. It is just a sad state of affairs.
| Nursie wrote:
| How so?
|
| Not that I disbelieve, I just wasn't especially picking that
| up from the article.
| la_oveja wrote:
| 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.
| orthoxerox wrote:
| Do they? I thought Lunar Lake was an incredibly good
| efficiency generation.
| high_na_euv wrote:
| It is
| adrian_b wrote:
| 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).
| FirmwareBurner wrote:
| _> 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.
| baq wrote:
| 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.
| xxs wrote:
| it's a very good article.
| wuming2 wrote:
| Substack.
| onli wrote:
| 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.
| vladvasiliu wrote:
| 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?
| onli wrote:
| 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.
| KronisLV wrote:
| > 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).
| Aurornis wrote:
| > 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.
| onli wrote:
| 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.
| anonymars wrote:
| They were cooking themselves at idle too (see microcode
| 12F) so it's not clear heat/throttling is relevant
| blacklion wrote:
| 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?
| onli wrote:
| 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.
| onli wrote:
| I found a bug in the score calculation that inflated the
| score, this case is closer now.
| jfindley wrote:
| 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).
| onli wrote:
| 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.
| mort96 wrote:
| > 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.
| pjmlp wrote:
| 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.
| jama211 wrote:
| 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.
| pjmlp wrote:
| Then why taking the effort to look better that it actually
| is?
| mort96 wrote:
| 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.
| jama211 wrote:
| Ok I'm lost
| raverbashing wrote:
| 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.
| pjmlp wrote:
| 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.
| CoastalCoder wrote:
| 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.
| pjmlp wrote:
| 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.
| CoastalCoder wrote:
| Fair. At the time I packed the necessary understanding to
| know of the GCC-emitted object code was significantly
| suboptimal.
| CoastalCoder wrote:
| s/packed/lacked/
| saati wrote:
| 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.
| dwattttt wrote:
| 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.
| sidewndr46 wrote:
| 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(r) Core(tm)
| 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/2410
| 60/...
|
| 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?
| flohofwoe wrote:
| > 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 ;)
| pjmlp wrote:
| 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.
| mathiaspoint wrote:
| 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.
| vel0city wrote:
| > 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.
| mathiaspoint wrote:
| 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.
| vel0city wrote:
| > 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?
| adgjlsfhk1 wrote:
| 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
| vel0city wrote:
| Posted by: Anonymous
|
| Yeah, real official documentation there.
|
| Got anything more real in terms of documentation other
| than a forum post by anonymous?
| biggoodwolf wrote:
| S1 S2 S3 S4 sleep modes and what happened to the most
| useful of them ;)
| const_cast wrote:
| 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.
| vel0city wrote:
| > 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.
| const_cast wrote:
| > 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.
| vel0city wrote:
| > 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.
| gruturo wrote:
| 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.
| p_ing wrote:
| 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.
| SleepyMyroslav wrote:
| 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.
| dandellion wrote:
| 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?
| pjmlp wrote:
| 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.
| Retric wrote:
| 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.
| izacus wrote:
| 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?
| Retric wrote:
| 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"
| vel0city wrote:
| 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.
| Retric wrote:
| 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.
| kcb wrote:
| 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.
| StillBored wrote:
| 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.
| dist-epoch wrote:
| > 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.
| StillBored wrote:
| 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.
| cogman10 wrote:
| 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.
| dist-epoch wrote:
| 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...
| giingyui wrote:
| 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.
| mcraiha wrote:
| Old games won't get updates. That is why there are multiple
| separate tools that try to force the situation. e.g. Process
| Lasso
| xxs wrote:
| > 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.
| onli wrote:
| 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.
| Havoc wrote:
| 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
| vladvasiliu wrote:
| 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?
| dur-randir wrote:
| It doesn't matter to the public's perception.
| vladvasiliu wrote:
| 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?
| p_ing wrote:
| OS scheduler is responsible; AMD/Intel work with
| Microsoft on the NT scheduler and likely contribute code
| on the Linux scheduler.
| masklinn wrote:
| 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.
| Havoc wrote:
| It is the OS fault as you say but consumers don't care
| who's fault it is only that it's broken
| SleepyMyroslav wrote:
| 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.
| zamadatix wrote:
| 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.
| smileybarry wrote:
| 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.
| Aurornis wrote:
| > 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.
| barkingcat wrote:
| Pretty sure the mainstream gaming advice is to _turn off_
| E-Cores so the vast majority of actual gamers would be doing
| just that.
| MangoToupe wrote:
| 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.
| MobiusHorizons wrote:
| 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.
| moffkalast wrote:
| Say, is there any talk about Intel working on an AMD Strix Halo
| competitor, i.e. quad channel LPDDR5X in the consumer section?
| jeffbee wrote:
| I am still waiting on evidence that memory architecture helps
| anyone.
| moffkalast wrote:
| 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.
| jeffbee wrote:
| Did you read the article?
| moffkalast wrote:
| 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.
| jeffbee wrote:
| Yeah, _latency_. Strix has higher bandwidth but it pays
| for it in higher (i.e. worse) latency.
| moffkalast wrote:
| They literally say AMD gets better latency on top of
| better bandwidth, are we reading the same sentences?
| Better = lower I would expect.
| jeffbee wrote:
| 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.
| fortmeier wrote:
| I would like to understand more of the article, which book should
| I read?
| yvdriess wrote:
| https://archive.org/details/computerarchitectureaquantitativ...
| throwaway31131 wrote:
| 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.s
| fu.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.
| celeritascelery wrote:
| 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
| fschutze wrote:
| 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?
| yvdriess wrote:
| 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.
| fschutze wrote:
| Interesting. You realize this by identifying the offending
| assembly instructions and then see that one operands comes
| from memory?
| Avlin67 wrote:
| I suggests using a Xeon w7 2595X so that you have 26P cores and
| 0E cores
| ece wrote:
| Another article with some original slides from Intel.
| https://www.hwcooling.net/en/intels-new-p-core-lion-cove-is-...
| Sohcahtoa82 wrote:
| 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?
___________________________________________________________________
(page generated 2025-07-07 23:01 UTC)