Most games aren't CPU bound anyway, would be interesting to see compiler benchmarks or other tasks that actually stress the CPU.
With the important disclaimer that this obviously is different for everyone. I play a lot of simulation/strategy games (like Cities: Skylines and Hearts of Iron) and most of the games I play actually are CPU bound, especially in later stages of the games.
So, while saying most games is true, it's still a good junk of players that do play CPU bound games.
If something is in L3 it is better for CPU "utilization" than stalling and reaching out to RAM. I guess there are eventually diminishing returns with too much cache, but...
Any mid+ CPU will easily pump out 240FPS on Counterstrike or Valorant.
But I've heard of triple buffering setups where you're displaying the current frame, and once you have a complete next frame, you can repeatedly render into the second next frame, but the next frame isn't swapped. In that case, it's hard to argue for any gain, since your next frame is way old when it's swapped to current.
Some rendering systems will do double buffering where the render is scheduled to start just in time to finish with a small margin before vBlank. If you've got that tuned just so, that's almost the same latency benefit as running unlocked, but if rendering takes too long you have a stutter.
Did you mean chunk, or is junk the actual term?
or various accidentally quadratic functions
of course they shouldnt, but such is life
sadly after few years faster CPUs are normalized and we write sloppier code that makes the programs slow again
then amd has to work on next generation of speculative execution innovations and almost AGI branch predictors :) and we go again
Also, "perfect storm of bad coding" is the norm for games, and not the exception, no?
I usually upgrade my CPU just to prevent it from becoming a bottleneck (that's the official version, I very often buy technology for the sake of having cool new technology, who am I kidding). So a CPU upgrade hadn't been something that made a game "playable" for me since GPUs became a thing. But when I got my 7800X3D, that was the difference between having reached a limit with my Factorio megabase and being able to keep building it bigger!
Also, since the simulation in that game has to churn through a lot of data in every tick, it's also a rare case in general where RAM speeds have a visible effect.
So this very much depends on which games you test and how you configure them graphics-wise. AMD was accused of heavily skewing their initial marketing numbers when introducing Zen5, almost exclusively testing with older games and testing them with very weak graphics cards to make them GPU-bound. In this case, MSI only tested with three games, which is a tiny, tiny data point. Channels like HardwareUnboxed test with up to 30 games to get a complete picture of the performance.
So then the economy of scale changes it a bit, and maybe they can make abstractions which use many cores under the hood, hiding the complexity?
You still have to know what you're doing. Cities: Skylines 2 is a good example, as the first installation had awful performance when playing bigger cities, and it wasn't very good at parallelizing that work.
For the second game, they seem to have gone all in with Unity ECS, which changes your entire architecture (especially if you use it wholesale like developers of Cities: Skylines did), which is something you have to explicitly do. Now the second game is a lot better at using all available cores, but it does introduce a lot of complexity compared to the approach they took in the first game.
But there are certain games which in addition are heavily bound by single-thread performance, although they are using Unreal, probably the most prominent lately being Star Wars Jedi Survivors, which isn't fixed to this day. You can watch Digital Foundry's video for details: https://www.youtube.com/watch?v=uI6eAVvvmg0
Why exactly this is no one can say apart from the developers themselves.
This problem is so obvious and widespread now, I wish there was a toggle/env var where I could decide I'm willing to have longer loading-screens rather than in-game stutters/"magically appearing objects", just like we had in the good old days.
Some games use a small percentage of my available VRAM and/or RAM, yet they decide to stream in levels anyways, regardless of it not being needed for any resource-usage reasons.
Very few gamers have that much RAM, none have that much VRAM. Many assets also aren't spatially correlated or indexed, so even though a whole "level" might be discrete enough to load specifically, the other assets that might be needed could still encompass nearly everything in the game.
For these games, amounts of memory in between those two thresholds aren't especially beneficial. They'd still require asset streaming, they'd just be able to hold more assets at once. That sounds better, and in some cases might just be, but really the issue is boiling down to knowing what assets are needed and having already loaded them before the player sees them. That's a caching and prediction problem much more than a memory size problem.
If you look at consistent player numbers, some top games are CS2, Valorant, WoW, FXIV, LoL and Dota2.
Competitive FPS are CPU bound as they are easy to run, but people want the highest framerates possible due to new 200+hz screens and general player input is better with higher framerates.
MMOs are CPU bound once you get into large groups and into big towns with lots of players, even brand new MMOs like Throne and Liberty.
MOBAs Im not sure, but in general, same with FPS games. More framerates = good for player input. These games are not a single player game you lock at 30 or 60 frames.