4 ms·

As a gamedev I found that... weird. A CPU for games would have very fast cores, larger cache, faster (less latency) branch prediction, fast apu and double floa

by speeder 10y ago

As a gamedev I found that... weird. A CPU for games would have very fast cores, larger cache, faster (less latency) branch prediction, fast apu and double floating point. Few games care about multicore, many "rules" are completely serial, and more cores doesn't help. Also, gigantic simd is nice, but most games never use it, unless it is ancient, because compatibility with old machines is important to have wide market. And again, many cpu demanding games are running serial algorithms with serial data, matrix are usually only essential to stuff that the gpu is doing anyway. To me, cpus are instead are optimized for intel biggest clients (server and office machines)

Thaxll 10y ago
Modern Engines take advantage of every cores usually.
- ss248 10y ago
  Developers don't care. Games are usually optimized for 4 cores max. For example, i7-6700K (4 cores) perform better than i7-6950X (10 cores) in almost every modern game.
  - johncolanduoni 10y ago
    That's also because a 10 core chip takes a significant hit on single core performance over a 4 core one. It's also quite likely that spreading out over more cores would be counterproductive. Many problems are not parallizeable indefinitely.
  - tarpherder 10y ago
    I don't understand how you can say such a blatantly false thing. Modern consoles have more than 4 cores available, do you really think we would let the other 3 go to waste? Large games will use all cores, our game uses 32 cores if you have them, we solved a bug because 1 guy had such a machine and reported an issue. 1 guy, from the public, and we fixed it the next update! But no, developers don't care, we don't even like games! In fact, we hate games! Please don't enjoy our games!
  - lagadu 10y ago
    This is changing very rapidly with the introduction of the low-level APIs like Vulkan and DX12 that were designed to scale on multicore systems. On those titles we've been seeing much better use of multi core resources than we saw on previous generations [0][1] [0] http://www.pcworld.com/article/3039552/hardware/tested-how-many-cpu-cores-you-really-need-for-directx-12-gaming.html http://www.pcworld.com/article/3039552/hardware/tested-how-m... [1] https://imgtec.com/blog/vulkan-scaling-to-multiple-threads/ https://imgtec.com/blog/vulkan-scaling-to-multiple-threads/
Arzh 10y ago
Yeah it also seemed like a weird analysts of what games would need from the CPU.
sapphireblue 10y ago
>A CPU for games would have very fast cores, larger cache, faster (less latency) branch prediction, The CPU industry stayed on this path for as long as it were physically possible, even long after the time when it hit diminishing returns on single thread performance divided by (area*power). Pentium 4 was the last CPU of this single-core era. If you look closely at the microarchitecture of the modern desktop CPU, the out-of-order execution, caches and branch prediction are already maximized (to the point that >2/3ds of die area is cache). Multi-core has become mainstream only after all other paths became exhausted.
- forgotpwtomain 10y ago
  The reason Moore's law failed to keep pace is as you start to pack the transitors close enough you get a lot more heat and current leakage, the amount of work spent doing error correction increases quickly and becomes prohibitive.
  - yvdriess 10y ago
    Maybe you mean Dennard scaling (https://en.wikipedia.org/wiki/Dennard_scaling https://en.wikipedia.org/wiki/Dennard_scaling), Moore's Law is seen to still continue economically to 2021 according the the latest ITRS.
pcwalton 10y ago
> Also, gigantic simd is nice, but most games never use it, unless it is ancient, because compatibility with old machines is important to have wide market. In my experience SIMD actually becomes more important when you want compatibility with old machines, because your ability to use the compute power of the GPU becomes more limited the further back you go in graphics library versions. For example, OpenGL has no compute shader before 4.6, no tessellation shader before 4.0, and no transform feedback before 3.0. When you can't make the GPU do what you want, SIMD becomes your best bet…
SolarNet 10y ago
I disagree. As a gamedev writing game logic you are right. But as an engine programmer, I agree with the linked author. I'll take your points one at a time. Most engines are multi-core, but we do different things on each core (and this is where Intel's hyper-threading, where portions are shared between the virtual cores, for cheaper than entire new cores, is a solid win). Typically a game will have at least a game logic thread (what you are used to programming on) and a "system" thread which is responsible for getting input out of the OS and pushing the rendering commands to the card along with some other things. Then we typically have a pool of threads (n - 1; n is the number logical core of the machine; -2 for the two main threads, +1 to saturate) which pull work off of an asynchronous task list: load files from disk, wait for servers to get back to us, render UI, path-finding, AI decisions, physics and rendering optimization/pre-processing, etc. AAA game studios will use up to 4 core threads by carefully orchestrating data between physics, networking, game logic, systems, and rendering tasks (e.g. thread A may do some networking (33%), and then do rendering (66%), thread B might do scene traversal (66%), and then input (33%), see the 33% overlap?), they also do this to better optimize for consoles. But then they have better control of their game devs and can break game logic into different sections to be better parallelized, where as consumer game engines have to maintain the single thread perception. SIMD is used everywhere, physics uses it, rendering uses it, UI drawing can use it, AI algorithms can use it. Many engines (your physics or rendering library included) will compile the same function 3 or 4 different ways so that we can use the latest available on load. It's not great for game logic because it's expensive to load into and out of, but for some key stuff it's amazing for performance. That stuff the GPU is doing eats up a whole core or more of CPU time. So what if we are generally running serial algorithms, we need to run 6 different serial algorithms at once, that's what the general purpose CPUs were built for. This is all the stuff you don't often have to deal with coddled by your game engine. The same way that webdevs don't have to worry about how the web browser is optimizing their web pages.
- yoklov 10y ago
  Glad somebody wrote this. I agree 100% (well... probably more like 90% -- but mostly nits that aren't worth getting into).
bitmapbrother 10y ago
>Few games care about multicore Pretty much all console games care about multicore.

by speeder 10y ago

Thaxll 10y ago

Modern Engines take advantage of every cores usually.

ss248 10y ago
Developers don't care. Games are usually optimized for 4 cores max. For example, i7-6700K (4 cores) perform better than i7-6950X (10 cores) in almost every modern game.
- johncolanduoni 10y ago
  That's also because a 10 core chip takes a significant hit on single core performance over a 4 core one. It's also quite likely that spreading out over more cores would be counterproductive. Many problems are not parallizeable indefinitely.
- tarpherder 10y ago
  I don't understand how you can say such a blatantly false thing. Modern consoles have more than 4 cores available, do you really think we would let the other 3 go to waste? Large games will use all cores, our game uses 32 cores if you have them, we solved a bug because 1 guy had such a machine and reported an issue. 1 guy, from the public, and we fixed it the next update! But no, developers don't care, we don't even like games! In fact, we hate games! Please don't enjoy our games!
- lagadu 10y ago
  This is changing very rapidly with the introduction of the low-level APIs like Vulkan and DX12 that were designed to scale on multicore systems. On those titles we've been seeing much better use of multi core resources than we saw on previous generations [0][1] [0] http://www.pcworld.com/article/3039552/hardware/tested-how-many-cpu-cores-you-really-need-for-directx-12-gaming.html http://www.pcworld.com/article/3039552/hardware/tested-how-m... [1] https://imgtec.com/blog/vulkan-scaling-to-multiple-threads/ https://imgtec.com/blog/vulkan-scaling-to-multiple-threads/

Arzh 10y ago

Yeah it also seemed like a weird analysts of what games would need from the CPU.

sapphireblue 10y ago

>A CPU for games would have very fast cores, larger cache, faster (less latency) branch prediction, The CPU industry stayed on this path for as long as it were physically possible, even long after the time when it hit diminishing returns on single thread performance divided by (area*power). Pentium 4 was the last CPU of this single-core era. If you look closely at the microarchitecture of the modern desktop CPU, the out-of-order execution, caches and branch prediction are already maximized (to the point that >2/3ds of die area is cache). Multi-core has become mainstream only after all other paths became exhausted.

forgotpwtomain 10y ago
The reason Moore's law failed to keep pace is as you start to pack the transitors close enough you get a lot more heat and current leakage, the amount of work spent doing error correction increases quickly and becomes prohibitive.
- yvdriess 10y ago
  Maybe you mean Dennard scaling (https://en.wikipedia.org/wiki/Dennard_scaling https://en.wikipedia.org/wiki/Dennard_scaling), Moore's Law is seen to still continue economically to 2021 according the the latest ITRS.

pcwalton 10y ago

> Also, gigantic simd is nice, but most games never use it, unless it is ancient, because compatibility with old machines is important to have wide market. In my experience SIMD actually becomes more important when you want compatibility with old machines, because your ability to use the compute power of the GPU becomes more limited the further back you go in graphics library versions. For example, OpenGL has no compute shader before 4.6, no tessellation shader before 4.0, and no transform feedback before 3.0. When you can't make the GPU do what you want, SIMD becomes your best bet…

SolarNet 10y ago

I disagree. As a gamedev writing game logic you are right. But as an engine programmer, I agree with the linked author. I'll take your points one at a time. Most engines are multi-core, but we do different things on each core (and this is where Intel's hyper-threading, where portions are shared between the virtual cores, for cheaper than entire new cores, is a solid win). Typically a game will have at least a game logic thread (what you are used to programming on) and a "system" thread which is responsible for getting input out of the OS and pushing the rendering commands to the card along with some other things. Then we typically have a pool of threads (n - 1; n is the number logical core of the machine; -2 for the two main threads, +1 to saturate) which pull work off of an asynchronous task list: load files from disk, wait for servers to get back to us, render UI, path-finding, AI decisions, physics and rendering optimization/pre-processing, etc. AAA game studios will use up to 4 core threads by carefully orchestrating data between physics, networking, game logic, systems, and rendering tasks (e.g. thread A may do some networking (33%), and then do rendering (66%), thread B might do scene traversal (66%), and then input (33%), see the 33% overlap?), they also do this to better optimize for consoles. But then they have better control of their game devs and can break game logic into different sections to be better parallelized, where as consumer game engines have to maintain the single thread perception. SIMD is used everywhere, physics uses it, rendering uses it, UI drawing can use it, AI algorithms can use it. Many engines (your physics or rendering library included) will compile the same function 3 or 4 different ways so that we can use the latest available on load. It's not great for game logic because it's expensive to load into and out of, but for some key stuff it's amazing for performance. That stuff the GPU is doing eats up a whole core or more of CPU time. So what if we are generally running serial algorithms, we need to run 6 different serial algorithms at once, that's what the general purpose CPUs were built for. This is all the stuff you don't often have to deal with coddled by your game engine. The same way that webdevs don't have to worry about how the web browser is optimizing their web pages.

yoklov 10y ago
Glad somebody wrote this. I agree 100% (well... probably more like 90% -- but mostly nits that aren't worth getting into).

bitmapbrother 10y ago

>Few games care about multicore Pretty much all console games care about multicore.