How many cores do we need?!

Why I think you should watch this: Amdahls Law puts limits on the number of parallel cores that programs can take advantage of due to percentage of the program that needs to be serial being the limiting factor.



In games the serial aspect of the game could be classed as everything limited to the main thread e.g. rendering/input/file/io/networking or just the need for a common information bus e.g. events/system interaction points.

Or think of it in terms of Unity ECS code and CPU core counts:

• 50% -> 2x @ 16 cores.
• 75% -> 4x @ 128 cores.
• 90% -> 10x @ 1024 cores
• 95% -> 20x @ 4096 cores.

So for great ECS performance you and Unity need to go ECS pure (near 100% parallel) and we need platforms with > 8 cores.

It's a great argument for why ECS needs to move to the GPU for those higher performance tasks but also highlights diminishing returns without a near 100% ECS parallel game engine API.

Imagine a 95% parallel Unity ECS system that could take advantage of CPU/GPU cores and give you 10x-16x performance boost on a multi-core platform.

So will we see higher core count consoles/smartphones and desktop CPU's but will they hit a peak around the 64-128 core count where we hit diminishing returns e.g. 16x-18x or even lower down the scale at 16-32 cores?

 

Part of ECS discussion ignores the fact, that many calculations are not suitable for parallelism, and single, or fewer higher performance threads are more appropriate, than "too many" of them and small. And if watched video carefully, reason for that was highlighted.

ECS simply schedules jobs across available threads and if jobs are small, but many, simply puts jobs into queue, for next available thread. Hence is not really disadvantaged from CPU.

Not to mention, communication between CPU and GPU is not that great as we would like.

Also, GPU is enough occupied by rendering graphics anyway, while most games underuses available power of CPU threads.

Hence I am glad, Unity ECS plans is to operate on CPU, leaving graphics for GPU.

 

Ah I see you have never been a part of a "great argument." As mentioned, parallelism is not the solution to all, or even most problems. A lot of things thrive on single-core operations because how they function is not meaningfully benefitted from multicore.

People use their computers for far more than just videogames.

 

It seems that the old roof has been broken since they have been able to go beyond 5nm without quantum tunneling. But soon we will see a stop to what can be done with semi conductors. Parallelism is the only way out of that until we have new reliable and cheap alternatives (quantum computers are decades away for personal computer use).

I have been nagging on Unity for a long time to prioritize Vulkan and gfx jobs higher (especially in conjunction with single pass and single pass instanced). but no reaction sadly.

 

As multithreading becomes more important due to core count increases, you'll get:

A) more/better programming language support to ease development of multithreaded code (including unity's HPC# as an example, with its better readonly attributes etc)
B) likely architectural changes to reduce the overhead of waking up threads & synchronization, allowing smaller tasks to be multithreaded effectively
C) big.LITTLE style cpu's with some quick cores and many slow cores - run the things you can't thread on the quick ones, run the threaded ones on the slow cores.

As average core count goes up, these points will become more important to people/devs and thus get more attention & progress.

Also, even if manufacturing sizes don't improve further due to possible physics issues we would still be expecting improvements in $/mm2 die space, which I can see dropping a lot if we get stuck on a nm size (as that's where you'll end up competing then). Having dies that are a lot cheaper would also allow much more specialized hardware inside of the cpu (which mostly idles behind a power gate until required).

 

You are jumping to the wrong conclusion here. You can get a benefit from ECS without "needing" more than 8 cores. Systems with 4-8 cores will benefit from ECS. ECS would continue to benefit from additional cores past 8 cores, but you would not "need" more than 8 cores to take advantage of the benefits of ECS.

 

On a well optimised game targeting mainstream platforms, is the GPU not typically the bottleneck rather than the CPU?

On a case-by-case basis there still may be gains by moving stuff to the GPU. Broadly speaking, though, there would be a negative performance impact for blindly moving everything from the CPU (an often under utilised resource) to the GPU (an often fully utilised resource).

Imagine you're moving house and you've got a faster truck and a slower truck. In most cases, the move will still be completed more quickly if you use both trucks.

I haven't tried it, but I suspect that systems with a single core would also benefit from ECS, purely because it gets coders to prepare data in a way that's more efficient for computers to work with. Of course, you don't need ECS to do that.

 

Yes, and it's not like we're close to running out of ideas for improving our visuals any time soon. Hardware raytracing is the latest idea and it's a massive performance hog. Last I looked into it a month or two ago it was cutting performance in half for many games running it at just a "medium" setting.

Offloading calculations to the graphics hardware made sense back when Intel was artificially limiting their core counts to four or less, but with the current and upcoming generations continuing to increase core counts that's largely no longer the case right now. Whether and by how much that will change we'll have to wait and see.

 

Let's pause for a moment and consider the benefit of this is not necessarily limited to the same program, at the same time.

 

Which "this"? ECS or GPGPU usage?

 

Any number will perform better with good memory management like ECS