I think what AMD is really trying to do, or what they should do, is place emphasis on the gaming community and drop any/all enterprise related features, and let Intel keep doing that part.
Intel's 7700Ks can easily hit the 5ghz mark on aftermarket air and AIO water cooling.
Games aren't optimized well beyond 2 cores, with games that are optimized for more than 4 cores being particularly unheard off.
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.
The worst case for Zen is going to be the not here and not there CPU, with price slashed 7700K mopping the floor with 8C Zen CPUs in gaming because they can clock to 5ghz and higher while it's unclear if AMD can even hit 4ghz reliably on all cores and on the other hand the Zen ecosystem not being mature enough for the prosumer and professional types due to subpar support/performance of storage, peripherals and memory.
The biggest mistake I made is getting a 2nd 5820K for my gaming rig, I got it cheap so I don't mind but performance wise I would be better off with a 6700/7700K. And I'm lucky as my 5820K hits 4.5-4.6ghz with an AIO cooler.
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%.
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.
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.
>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.
- 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.
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?
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.
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.
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%
;)
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.
Given that AMD is part of the OpenCAPI consortium, they could potentially make monster HPC machines with Infiniband and GPU's connected with cache coherent OpenCAPI instead of PCIE.. But we'll see, I guess..