Hacker News Reader

This is increasingly untrue. Modern consoles like the Xbox One and PS4 guarantee availability of six hardware threads with provisional access to a seventh. This combined with things like VR putting a premium on high FPS has motivated more parallel architectures.

Most game engines architectures have supported limited parallelism in the form of dedicated game simulation and render threads, as well as often having asynchronous processing of audio, network, and IO. More modern engines have task based architectures that allow for parallelism of the game simulation. This is often implemented as a fork-join model around sync points spread throughout the simulation update: pre-physics and post-physics update periods for instance. While it is true that some game logic relies on knowledge of global state and complicated dependencies between entities in the simulation, games can and do find meaningful reductions in CPU wall time.

50% of the PC gaming market is dual core, there are plenty of benchmarks that show it.

I wish this was increasingly untrue.

Running For Honor just now a new title built for consoles one CPU core is at 100% the rest are <10%

;)

Sure, the Steam Hardware Survey indicates as much. Most AAA games, however, sell the vast majority of their units on console platforms that have eight cores. If you are a developer/publisher targeting the top end of the market, you are highly incentivized to take full advantage of the multi-core console architecture. Also, the trend in CPU desktop architecture for the past decade has been more cores versus higher frequencies or large IPC improvements. Might as well architect your technology for parallelism now (consoles) and the future (mainstream PC consumers moving to four, six, and eight core processors). Those technology investments and trends eventually trickle down to smaller developers who aren't developing their own proprietary engines.

Again this isn't about steam hardware survey it's about reality.

Out of the lastest 10 AAA titles only one I would call something that might be worth more than 4 cores and it's WD2.

2 cores on 100%, 2 more on 60-70% and 2 more on 20%. W/ HT it will be 2, 100% and the 10 left "cores" at about 15%.

And this is by far the best "multithreaded" game that came out in the past 8-12 months.

What devs do for consoles doesn't translates to PC, PCs come with a huge variety in hardware and unlike consoles where devs get 6-7 cores out of the 8 exclusively for their game on a PC they have to live with everything else from AV scans to Streaming.

No one is taking advantages of multicore CPUs because no one can do it right on a fragmented platform where you don't control over the runstate of the app, co-hosting and have zero knowledge about it's hardware and configuration.

> Games aren't optimized well beyond 2 cores, with games that are optimized for more than 4 cores being particularly unheard off.

How much of that is a chicken-and-egg problem? Gamers buying hardware look for clock speed over core count because that's what today's games benefit from, therefore developers don't optimize for higher core counts because customers don't have them now.

> Games aren't an application that supports parallelism that well since your sound, physics, AI and graphics threads all have to be synced within a single frame otherwise everything falls apart.

I've often heard that repeated, but I'm not sure I totally understand why. I admittedly haven't looked at anything resembling a modern game codebase -- my last time in that space was eons ago in programmer years -- but my instincts would say that doesn't necessarily have to be true, or at least not for that reason.

Graphics and sound kinda make sense, in that you're trying to push out pixels/samples at a fast & regular rate and they need to be perfectly aligned. Though does anything not primarily rely on GPU (which is itself massively parallel) for most graphics work nowadays? Given that, I'd assume the CPU's part of graphics is mostly a support role moving stuff on and off the GPU.

For aspects like AI and physics, I'm not convinced they do have to be locked to frame rate like you say. Why can't they run independently and continuously and let the game take advantage of the "most recent" state of the world as often as needed to match the frame rate? There may be design/architectural reasons this isn't done, but I don't see any fundamental reasons that it couldn't.

Maybe there are factors I'm just missing or not aware of, I'd love to see a good solid analysis of why this is true, if it is.

Dual Core CPUs are still 50% or so of the current gaming PC audience based on steam hardware surveys, chicken and egg or not but until 4+ core CPUs make the bulk of the market game developers will optimize their games for 2-4 cores.

>For aspects like AI and physics, I'm not convinced they do have to be locked to frame rate like you say. Why can't they run independently and continuously and let the game take advantage of the "most recent" state of the world as often as needed to match the frame rate? There may be design/architectural reasons this isn't done, but I don't see any fundamental reasons that it couldn't.

AI and Physics define what is going to be displayed on a screen if say you doing cloth physics this will change the animations of a flag weaving in the wind, if there are thread locks the animation will be breaking up and be choppy. It's even worse if the physics have actual game implication does a barrel hit a player or not if a frame is skipped? And then we get into the realm of multiplayer where you don't just need to sync things within a single computer but between multiple computers all over the world.

Everything has to be synced to make the game work, can it be split across 10 cores probably, but since most gamers don't have 10 cores you better work with 2-4 cores and make sure it works well.

If you've already optimized your game for 2-4 cores, is it that much harder to make it run well on more than 4 cores?

Yes.

People down vote this, so I will provide a bit more explanation: Parallelism is 'easy' as long as you have natural separated problems. This is the reason embarrassingly problems are so great for many-core systems. Every single sub-problem can be done without having to synchronize with other parts of the system. Unfortunately, most problems aren't that way, but instead are interlocked on multiple axes:

- Minimal granularity: You can never run more cores than you have problems at the same time, but you also cannot just split problems as long as you want or the overhead of splitting will kill all performance gains you'd had (x+y in an extra thread/process is technically possible, in reality pretty stupid)

- Synchronization points: Most problems are not completely separate from each other, so you can do part of the problem in parallel but at some point you have to converge and do something with the combined result.

- Comparable task size: In an ideal world all of your tasks would take exactly as long as the other, because if one task takes far longer than the others you have to wait for it. So, the minimal run time of your parallel problem is bound by the time of your longest sub-problem. If one of the problems takes far longer than the others (and they depend on each other) you've lost.

The last one is more of a "meta" point: Complexity doesn't scale linear for dependent problems. That's another reason embarrassingly parallel problems are so nice. You cannot only run them all in parallel, you can think about each one as a completely separate problem. The moment you have dependencies you have to think about how to bring them all together and that gets hard very fast if you have many moving parts.

So, to sum it up: Many small things conspire against just scaling something which works great for two or four cores up to eight, 16, 32 or whatever. If you happen to have an embarrassingly parallel problem you're golden, but unfortunately only a small subset of interesting problems are that way and for other problems scaling is hard.

"In an ideal world all of your tasks would take exactly as long as the other, because if one task takes far longer than the others you have to wait for it. So, the minimal run time of your parallel problem is bound by the time of your longest sub-problem. If one of the problems takes far longer than the others (and they depend on each other) you've lost."

Could the cores that would otherwise be waiting for the longest sub-problem to complete start working on some new sub-problems to make the following set of sub-problems finish sooner?

If you have a set left that doesn't depend on the result of the problem still in computation you can do this, yes. Though in that case you don't actually have two sets, you have one set which is bigger than your core count. I simplified a bit before, but if you have more problems than cores your longest sub-problem shouldn't run longer than the time it takes you to compute all other sub-problems (i.e. that includes computing five sub-problems on one core while another core computes one longer problem) or you'll have to wait.

Unfortunately, I had this happen to a program of mine last year. All other tasks were long done but one kept running and running. The run time of the program escalated to hours with the first few minutes being marked by high usage of the system and then only one core in use, while everything else had to wait. It sucked.

Thanks for expanding on this. My answer of 'Yes.' deserved the downvotes.

Anecdatum, but the game I worked on (Tom Clancys The Division) will perform much better on a quad core than a dual core. We're CPU bound long before GPU bound.

Yeah the Division, AC, FC (all ubisoft games ;) and a few other games are pretty CPU demanding and will eat as much as you can give them but even those usually fizzle after 4 cores or so.

I find it hard to find a game that will use all 6c/12t on my 5820K, most of them will use 2-4 with usually 1-2 being pushed fully and 2 more between 10-25%.

Doesnt really matter when even a $65 G4560 hits reliable 80fps in division

Not really a a fair point. The G4560 is extraordinary value for the money. It is a dual core, but it has hyperthreading. And as much as I was surprised by this when the i3s showed it, hyperthreading helps a lot in situations where 4, well, I'd like to say cores, are expected. The G4560 is eating the whole budget processor market right now – but that does not mean that his example doesn't show something: There are a number of games by now that rely on having a processor that can power multiple threads. And those games profit a lot from having more cores – you can play with the Pentium, and it absolutely is the best pick for a budget build, but you still get budget performance. And that means there are some games that won't run very well with it, and some min-FPS will be lower than one would want.

The pendulum has swung so far far that (some) recent games began to run good on the old FX chips, see Watchdog 2. If not looking at budget chips, having multiple cores is attractive for gamers by now. Maybe the potential of hexa-cores is not used that much yet, but it is obvious that will come, and games like Battlefield 1 do use them already. I think those Ryzen hexa-cores have a very good chance at the market, if their single thread performance is high enough.

I feel that AMD forced that change in accidentally clever way by embedding itself in current generation of consoles. 8 anemic 1.6 GHz cores forced whole gaming industry to start taking multi threading seriously.