4 ms·
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. M
by 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 agoGlad somebody wrote this. I agree 100% (well... probably more like 90% -- but mostly nits that aren't worth getting into).
- SolarNet 10y agoTo be fair I'm more of a hobbyist - who writes game-engine-esque code (I never said what kind of engine programmer I am did I) for my day job (pays better) - that just builds game engines for fun (like the last 10 years now... but no games). So some details are likely wrong, I'm kinda super curious as to your nits.
- daemin 10y agoSounds like what I did for the past 10 years before joining the gamedev world about 3 years ago. It is cool to work on your own tech and to learn a lot of different things, but it's also scary how much can get done with a whole team working at it.