If the game has a CPU bounded work load that scales well across multiple threads/processes. Honestly, most games do not, and are likely gonna run into Amdahl's law much quicker than compilation.

Modern game engines can, yes

Games are typically written in C++, so that's a yes. As for the threading, older (2yr or so back) games tend to assume 4 cores and don't scale past that (thanks, Intel!). More recent games tend to aim at arbitrary horizontal scaling.

You do still get major titles that are completely single-threaded.

? no

The parent was talking about c++ compilation.

A c++ compiler is very different from a game engine written in c++.

written in C++ not means it's compatible workload. Gaming performance is just gaming. For gaming, realtimeness is important and normally single thread perf is important even though some process is multithreaded.

uh what??? No most games do no scale like compilation does. For instances when compiling a large program GNU make lets me the following: make -j 16

That will create 16 instances of the compiler each compiling different compilation units. I could even do the following: make -j 128 and that will spawn a 128 processes, and still scale. I can keep scaling this assuming I have enough compilation units (aka files)

Games use threads.

Compilation parallelism is generally bounded roughly the number of independent compilation units. For my main codebase, that is in excess of 1200. That is, on a system with 1200 cores, I could use all 1200 cores productively, at full capacity (ignoring disk i/o waits) [1]

My impression is that few games (if any) can ever approach this level of potential parallelism. There are not many tasks in computing with this level of "embarrassing parallelism".

[1] somebody actually did this with Ardour once, on a system with 1024 cores. The current normal-system compile time record for the software is a little under 5min (Ryzen Threadripper 2950X + 64GB of RAM). The k-core system completed the build in less than 10 seconds :)

Surprised that the record doesn't belong to a 32-core CPU, hmm. Quite interesting.

Any data on the precise machine specs that did the record? I'm talking about the TR 2950x one, not the custom-built many-core machine.

I'd be interested mostly in motherboard and RAM speed.

> My impression is that few games (if any) can ever approach this level of potential parallelism.

Which is embedded in my first comment on game multithreading: "older" games assume 4 cores, some are single-threaded.

This has no bearing on how new the engine is. The workloads scale much differently when it comes to parallelism. While it might possible to get a little more parallelism and concurrency with a newer engine. The ability to scale is much more limited for games.

Just because a game uses threads does not mean it can magically get rid of Amdahl's law. The CPU workload of games does not scale anything like compilation.

> does not mean it can magically get rid of Amdahl's law.

Neither can compilation.

I never claimed it did. Compilation is an embarrassingly parallel task. This means you can increase the number of threads by a much much larger amount before you hit Amdahl's law. That is not true for video games unless you count what runs on GPUs. Not only can it be less obvious on what to parallelize in a game engine. You quickly start to see the parallel slowdown/diminishing returns in game engines. Further, not every thread in video game is going to use the CPU at 100%, a lot them will be waiting on IO, and not using any time slices till that IO task is finished.

Games do not scale like compilation, it does not matter what engine or how new that engine is.

https://en.wikipedia.org/wiki/Embarrassingly_parallel https://en.wikipedia.org/wiki/Parallel_slowdown

> Further, not every thread in video game is going to use the CPU at 100%

Modern game engines do not segregate work according to threads, they use thread pools. If one green thread is busy with I/O, work can be scheduled on its OS thread.

https://en.wikipedia.org/wiki/Work_stealing