CPU Limited Games, When Are They Going To End?

[DavidGraham]

Somewhere along the way everyone forgot about that. It became too easy and simple to let some other library deal with it or to even worry about memory size minimizing.

Sebbi actually agrees with this, and he reinforces what others have been saying about some lazy aspects in development and writing codes.

It seems that most people don't want to learn writing efficient code, don't want to optimize code and don't want to profile code. Or the project schedule makes that unfeasible. The solution is simple, let's teach AI to do this unwanted work automatically...

Profiling is a time consuming process. The tools often have UIs that are hard to navigate and contain a lot of arcane data. AI would read this data much faster and it would understand it better. AI could do iterative optimization much faster than a human.

AI could run a frame capture repeatedly and optimize iteratively. Do A/B testing to select best optimization strategies. It could even do this while the program is running. Just iteratively analyze and optimize code all the time. Humans can never optimize code this fast.

Casey is complaining that programmers write slow code nowadays. Software runs 100x+ slower than it should be. It seems that we humans wasted all the extra CPU cycles we got in the past decades. AI can fix this. AI is not lacking motivation and it's better at processing big data.

If I would have my own AI startup, this would be an interesting topic to solve. AI would learn how source code maps to instructions and how those instructions map to cycles (after profiling). In other words, it would learn what kind of source code runs efficiently.

https://twitter.com/x/status/1638653136670695424

 

[techuse]

CPU performance requirements have skyrocketed with no change or improvement to the game experience. What else could it be besides unoptimized code.

 

[Scott_Arm]

I think the problem is the way programming is taught in universities and the way management in a lot companies function.

I started first year university in 1999 and the first thing we learned was object-oriented programming in Java. We didn’t learn how a computer worked and professors would frequently say things like, “You can’t out-optimize a compiler.” At the time memory was really fast relative to the cpu, compared to how it is now. Memory is getting slower and slower (latency) relative to cpu performance, even though per core increases are slowing down.

The industry really believed that the compiler would take care of performance and object-oriented code would lead to simpler and easier to maintain code bases. It didn’t really work out and the industry continually trained people to think of programming languages as platforms, especially interpreted languages, and to disregard the hardware. The games industry is one of the few performance areas where they had to care, and it even took a while for some of them to realize how much performance their new C++ code bases were leaving on the table. Hey it turns out we can generate cpu particles way faster if the data is pre-allocated and located sequentially in arrays instead of having a class or struct allocated per particle.

Now in the general software industry, the managers want developer “velocity” so they want to write once and have the program run on as many operating systems as possible. They want interpreters, micro services, portability, reusability, frameworks, open source libraries. The user experience is barely on the list, and they barely understand how fast software can be because they’ve only done the same thing for the last twenty years. It’s crazy how many programmers debug with print statements and have never seen a debugger or profiler.

Edit: and in the end a lot of things being done for velocity and maintainability just make programs harder to debug and understand. Also for the love of god, no more Agile.

 

[Athenau]

That objection oriented abstractions are frequently counter-productive doesn't say anything about the value of abstraction in general. Abstractions are meant to aid understanding. If your abstraction obfuscates instead, find a better one.

In many problem domains, writing something provably correct would easily be worth one or two orders of magnitude of performance. The problem is that the languages and tools in most common use today (Python and Javascript come to mind) prioritize initial productivity at the cost of both performance and correctness, so you get the worst of both worlds.

 

[Scott_Arm]

@Athenau Yah, I don't think object-oriented design is always bad. I think in a lot of cases it can be very bad for games, because games tend to deal with taking large batches of the same data type and transforming it with the same function. I'm not a person that's going to make blanket statements about how all programs should be written with one particular best pattern or level of abstractions. Right now I'm working on a very large software system, somewhat indirectly, but the way it's made is really just throw hardware at it until it works well. I imagine if someone had the "video game" mindset when developing it, this thing could run way faster, way better and use much smaller servers.

 

[davis.anthony]

A big problem is also people not upgrading their CPU's anywhere near as often they do a GPU upgrade.

It's very difficult to make a game to depend on 6, 8 or 12 threads when a lot of people are still gaming on a quad core with SMT.

And the isue with upgrading the CPU is it's not just the cost of the CPU itself but also motherboard and RAM so it can get expensive.

 

[Remij]

CPU performance requirements have skyrocketed with no change or improvement to the game experience. What else could it be besides unoptimized code.

Facilitated by the need to sell ever more powerful hardware.

 

[davis.anthony]

CPU performance requirements have skyrocketed with no change or improvement to the game experience.

Not really, a 12 year old 3920k can still deliver 60fps in 99.9% of PC games.

So while on paper they may have increased in reality 60fps hasn't required a massive uptick in CPU performance outside of some outliers.

 

[DegustatoR]

CPU performance requirements have skyrocketed with no change or improvement to the game experience. What else could it be besides unoptimized code.

I mean it could be cost reduction. You know, saving on optimizing the code. Sucks but it is a market where the less you spend the more your profits are.

 

[DavidGraham]

A good and popular example is Office, I remember it running very very well on a Pentium 4, new Office versions require significantly more CPU power despite them not offering major upgrades or features over the old ones.

 

[techuse]

Not really, a 12 year old 3920k can still deliver 60fps in 99.9% of PC games.

So while on paper they may have increased in reality 60fps hasn't required a massive uptick in CPU performance outside of some outliers.

I disagree. It's very difficult to maintain 60 fps in lots of modern games without a Zen 4/Rocket Lake CPU. And other than RT, games aren't doing anything they haven't been doing since the middle of last gen.

 

[davis.anthony]

I disagree. It's very difficult to maintain 60 fps in lots of modern games without a Zen 4/Rocket Lake CPU. And other than RT, games aren't doing anything they haven't been doing since the middle of last gen.

Outside of outliers like Spiderman (with RT on), The Witcher 3 (with RT on) there's very little games where the 3930k can not do a locked 60fps.

If you look at CPU reviews even low to mid end CPU are 100fps+ in pretty much every game: https://www.techpowerup.com/review/amd-ryzen-5-5600/14.html

If all you want is 60fps than a 10yr old CPU will do.

If you want high refresh you'll need something newer.

If you want to play modern games with RT enabled you'll need something released in the last 2-3 years.

 

[pcchen]

One of the reason why CPU is less scalable in games is probably because normally programming to use more CPU leads to gameplay changing behavior. For example, suppose that you want to use more CPU and decided to make buildings in your game destructible, and it's using something like 8 cores, for example. Now you'll find it's quite hard to run it well on a 4 core CPU. You can't just make an option to make buildings indestrutible on older computers, you'll be forced to make the minimum requirements high, and thus covering less audience (according to Steam HW survey, only ~30% PC are with >= 8 physical cores).

GPU scaling, OTOH, are relatively easy. Many effects can be turned off without affecting gameplay. If everything else failed, you can always reduce resolution, which is even more effective with DLSS or FSR nowadays.

What makes the situation sad is that there're still too many games heavily depending on single thread performance. They do use more than one core but the dominant thread still takes too long to complete (Amdahl's law). For example, if 33% of all workloads have to be in a single thread, then in theory you can't be faster with > 3 cores, as all other cores have to wait for that thread. Of course, this is very related to the "poorly optimized" problem.

 

[trinibwoy]

One of the reason why CPU is less scalable in games is probably because normally programming to use more CPU leads to gameplay changing behavior.

Purely visual effects like cloth or fluids seem like good candidates for pushing 8+ core CPUs yet even the latest games have surprisingly low fidelity cloth simulations. e.g. the cloth in the recent Lords of the Fallen UE5 trailer is quite stiff.

 

[troyan]

But isnt the GPU a much better processor for physics? Why use a CPU with limited ressources when a GPU has so many? It makes more sense to do host related work on the CPU and everything else should go to the GPU.

 

[trinibwoy]

But isnt the GPU a much better processor for physics? Why use a CPU with limited ressources when a GPU has so many? It makes more sense to do host related work on the CPU and everything else should go to the GPU.

Sure, but they're not doing it on the GPU either. Might as well use the free CPU resources. Probably easier to code on CPU too.

 

[Scott_Arm]

Yah, looking at the popular Jolt physics used in the Horizon games, it seems like it runs on CPU. I imagine there are some physics things that are more suited to CPU still, but not 100% sure.

GitHub - jrouwe/JoltPhysics: A multi core friendly rigid body physics and collision detection library. Written in C++. Suitable for games and VR applications. Used by Horizon Forbidden West.

A multi core friendly rigid body physics and collision detection library. Written in C++. Suitable for games and VR applications. Used by Horizon Forbidden West. - jrouwe/JoltPhysics

github.com

 

[pcchen]

Sure, but they're not doing it on the GPU either. Might as well use the free CPU resources. Probably easier to code on CPU too.

I guess that depends on whether you do model IK on GPU too. I know some engines use vertex shaders to do that, which may make it better to do cloth deformation on GPU too.
Of course, I agree that multiple core CPUs are quite capable of doing that, though moving model data from main memory to video memory is another thing to deal with. This is probably another advantage of a unified memory architecture.

 

[Scott_Arm]

I guess that depends on whether you do model IK on GPU too. I know some engines use vertex shaders to do that, which may make it better to do cloth deformation on GPU too.
Of course, I agree that multiple core CPUs are quite capable of doing that, though moving model data from main memory to video memory is another thing to deal with. This is probably another advantage of a unified memory architecture.

I want a PC that's basically a giant GPU with a cpu socket on it, lol. Make the GPU the motherboard and VRAM is also system memory.

 

[Lurkmass]

GPU acceleration for physics might sound like a good idea at first but CPUs naturally handle and access game logic so implementing a physics system over there is more easily extendible and convenient as opposed implementing it on a GPU. Programming languages on CPUs are more rich as well in terms of feature set compared to the shading languages on GPUs so programmers may be more productive as well on CPUs. Modern CPUs now feature powerful SIMD extensions such as AVX/AVX2 and eventually AVX-512 in the future which fits well with data-oriented design ...

CPUs also have more stable ISA designs which means less code refactoring needed overtime and a more future-proof/reusable/portable code in the event where future projects (updates/expansions/re-releases/remakes/reimagining) decide to revisit a codebase. Traditionally, code written for GPUs often won't "stand the test of time" and will be rotten by the end of the generation ...

The future of implementing physics systems on CPUs is brighter than many would imagine ...