4 ms·
Is anyone else in games development here? If we are looking to run the game at 60 FPS, we have 16.67 ms per frame to do everything required to run the game. Bec
by scraft 9y ago
Is anyone else in games development here? If we are looking to run the game at 60 FPS, we have 16.67 ms per frame to do everything required to run the game. Because of this real time requirement, a decent amount of profiling is typically done on each game. I typically see that the frame time is getting split up over a whole array of different sections of the game, i.e.:
- Calculating skeleton animations (updating bone positions, sometimes skinning vertices too)
- Clipping geometry in the scene (finding out what things are inside/outside the camera frustum, etc.)
- Processing game logic, things like AI can be quite costly, so much is game dependent
- Walking through all the geometry that needs drawing and issueing draw calls
- Decompressing streaming audio and sending it to a sound driver buffer/queue
- Stepping the physics world (integrating positions/rotation working and resolving out intersections, etc.)
The difference between a non optimized, and an optimized build, is often 5 FPS and 60 FPS, and optimizing a single hot file or function would not get the game running anywhere near 60 FPS. I think the idea that optimizing compilers aren't required is completely laughable, but then again I only have one perspective from the games development scene - maybe someone else will reply and say they make AAA games in C/C++ and don't need compiler optimizations :)
- AstralStorm 9y agoThose gains are often caused by globally applied optimizations like inlining and devirtualization. These then can enable actual stream processing and loop chunking optimizations which are of important but lesser effect. Perhaps dead code and constant elimination of you leave in flags. In other words, if you rewrite the algorithms from object oriented into stream processing, you would get most of the gains. This is caused by all CPU, FPU and GPUs actually internally being simple numerical stream machines.
- zurn 9y agoA bit of trivia: Computation is frequently pipelined so that part of the work is done during previous frame(s). This of course means that the game logic latency is longer than 1 frametime.
- mwkaufma 9y agoAAA dev here. The performance gains mostly come from designing data, not code. Factoring an array of structures into a structure of arrays and accessing linearly, e.g., makes better use of the processor cache and saturates throughput. Code optimization mostly gives us the confidence that there aren't unnecessary accesses or branches interleaved that might bust the cache.
- saosebastiao 9y ago> Factoring an array of structures into a structure of arrays and accessing linearly, e.g., makes better use of the processor cache and saturates throughput. This is an example of a provably correct optimization, and it's a shame that more compilers do not optimize this situation. Wouldn't it be awesome to model the data the way that makes sense for your domain and let the compiler worry about cache locality?
- zurn 9y agoJonathan Blow's Jai language lets you do this by annotating structs, along with some other assisted memory optimizations (pointer compression is another).
- AstralStorm 9y agoI suspect GCC could do it too for invisible or fully inlined symbols. This is possible in C99 and C++11 because type punning is forbidden in general. But that would need a special flag to specify incompatible internal ABI.
- mwkaufma 9y agoWell, in C memory is explicitly laid out, so it's not on the optimizer's menu, and in a dynamic language the runtime flexibility rules out most data-layout optimizations beyond occasionally coalescing a dictionary into a memory-offset-based buffer. There's some experimental game languages like JAI which include these semantics as a language primitive, but it's still declared rather than implied. Fundamentally, data layout is design because it depends on actual game content, and not just code; it's categorically different than code optimization.