Elysian Shadows

Editing this into something worded a little better.
Original post

I am looking into getting a new pc and the thought crossed my mind as I noticed a 10 core cpu as an option - what is the max number of cores that modern software utilizes?

I'm looking into either building or purchasing a new PC with the following uses in mind:

Game Dev in 3D and 2D
Working with Unreal Engine and/or Unity 3D
Possibly working with modeling tools like Blender, etc

I'd like to also setup multiple VMs to code/test with in other environments besides my base environment (Win 10 or Win 7) so, probably a Mac and Linux VM.

In addition to this I'll probably be playing some more modern games like Star Wars Battlefront as well.

My thoughts were

Intel i7 - 7700k
16-32 GB Ram
1 TB SSD (may consider a combo solution with an SSD for boot and regular HDD for storage)
NVIDIA video card mid with at least 4-8 GB of Video Ram

Any suggestions?

mattheweston wrote:I am looking into getting a new pc and the thought crossed my mind as I noticed a 10 core cpu as an option - what is the max number of cores that modern software utilizes?

Based on nothing other than intuition, I would say 2-4 is probably average. That said, if you're running more than 1 process at time (you are), the OS can offload work onto the cores. The more important part is whether those are "real" cores or "hyper-threaded" cores, or some other similar pseudo-virtualization stuff. You should also pay special attention to the power consumption / heat dissipation requirements. There are a lot of things that affect CPU performance aside from # of cores, so definitely check out some benchmark charts (https://www.cpubenchmark.net/) for real performance numbers. Pay attention to the cache sizes on the spec sheet as well (L1, L2, L3, etc.).

Wrong!

USUALLY most processes use only a single core. Multithreading in most languages and environments requires extra work and thought to be put into the software architecture and DEFINITELY is not something that happens automatically.

I do not know how Unity and Unreal handle things, but I would be quite shocked if most modern games used more than a few threads (which may or may not actually be mapped to separate cores) TOPS and 99% of indie games using only a single thread.

A game engine is traditionally not something that benefits immensely from multithreading, as no game in its right mind is blocking on IO consistently... Then most highly-parallelizable problem sets within gaming tend to lend themselves better to data-level parallelism rather than instruction-level parallelism. That's where GPGPU is coming into play for things like hardware accelerating a physics engine... It's parallelized on the GPU, not CPU.

Then you also have to keep in mind that a multithreading environment comes with its own inherent overhead as well... Obviously you're duplicating the runtime stack and local data, but more importantly there is a large amount of programming complexity that becomes introduced for synchronization and data protection. Quite often this is enough to destroy any benefits you would get from parallelization.

The few scenarios where multithreading MAY make sense in game development are:

• Streaming Assets - whether it be textures, audio, or video, it's useful to defer file accesses to separate threads, so the entire engine doesn't have to block on a disk read. Elysian Shadows gives each simultaneously playing OGG track its own thread, so that the main engine isn't blocking while the OS tries to load OGG data from the hard drive... but honestly, I'm mostly doing it this way for mobile devices, consoles, and because I'm a perfectionist. A modern engine can TOTALLY just load the entire fucking OGG into RAM and not need to bother with streaming.
• Networking - this is one of the main ones. It's very useful to defer networking logic to another thread so that the main logic is not blocking while the OS transfers packets... But actually even then, I just did the networking code for EVMU with all nonblocking OS calls being polled every frame... I have no doubt this is actually superior to a multithreaded implementation, as it's not like I will ever need the updated data mid-frame, I'm already not waiting on incoming data, and I would have to introduce additional complexity to synchronize the threads and data.
• Rendering - Despite what people may think/say, this is actually not usually beneficial in game development... It's ONLY beneficial when you have a shitty driver or are transferring a massive amount of data to or from the GPU. In that scenario, it allows the game logic to continue executing without having to wait for the transfer to the GPU to succeed... But in actuality, MOST OpenGL drivers are multithreaded to begin with, and are usually queueing GPU commands to be flushed asynchronously later, so this is already done under-the-hood behind-the-scenes for you... Also modern GPU usage paradigms these days are moving more and more data to the GPU, so that there is less and less need for these kinds of frame-by-frame transactions anymore. But even in the olden days of yore and on older consoles with a fixed-function pipeline, where each frame requires a massive amount of data transfer, a separate thread for GPU transfers STILL didn't make much sense. Don't forget that it's not like you are calling memcpy() or are using code to transfer that kind of data. That's where asychronous DMA transfers come into the picture... That's why the DMA exists. It's an entire piece of hardware dedicated to offloading data transfers asychronously. That's how most CPU/GPU transactions are handled on the DC, and I'm sure that's still how most every console, including the PC (including multithreaded implementations) are handling it.

There are probably a few other good examples out there too, but video games do not tend to make heavy use of threads.

Falco Girgis wrote:There are probably a few other good examples out there too, but video games do not tend to make heavy use of threads.

That is all excellent information which I 100% agree with, but he didn't ask about "modern video games", he asked about "modern software".

A *lot* of modern software is written to take advantage of multi-threading. E.g. Google Chrome is highly multi-threaded is one of the most often run applications on my computer. Also, as I briefly mentioned before, all modern operating systems make heavy use of multi-tasking which doesn't require individual processes to be multi-threaded at all in order to take advantage of multiple cores.

dandymcgee wrote:

Falco Girgis wrote:There are probably a few other good examples out there too, but video games do not tend to make heavy use of threads.

That is all excellent information which I 100% agree with, but he didn't ask about "modern video games", he asked about "modern software".

A *lot* of modern software is written to take advantage of multi-threading. E.g. Google Chrome is highly multi-threaded is one of the most often run applications on my computer. Also, as I briefly mentioned before, all modern operating systems make heavy use of multi-tasking which doesn't require individual processes to be multi-threaded at all in order to take advantage of multiple cores.

Eh, you're kind of right, it looks like. I just saw the game development stuff in his software list and ran off to type an essay, because I'm highly opinionated on the matter and saw what I wanted to see.

Google Chrome is actually not highly multithreaded. It's multi PROCESS, which is quite a bit different, but that's also why it's such a fucking RAM whore and as far as core utilization goes can be thought of the same way.

The OS-level multitasking you're talking about will benefit overall system performance when you have multiple single-threaded/single-process applications open at once, but it's not benefitting the speed of them individually as they will only have affinity for one core. For INDIVIDUAL applications to achieve any benefits from being run within a multicore environment (other than obviously maybe getting more CPU time to itself), it does have to either be written in a language or framework that handles it automatically or needs to have been architected to support that.

Falco Girgis wrote:Eh, you're kind of right, it looks like. I just saw the game development stuff in his software list and ran off to type an essay, because I'm highly opinionated on the matter and saw what I wanted to see.

It's a great essay either way. I always enjoy reading your essays. :P