Creeping inefficiency

July 23, 2014 | Filed under: programming

Here is why I reckon that triple-A game runs slow on your PC. The real reason :D

Step 1: Geniuses at Intel / AMD / ARM design an unbelievable;e processor capable of a bazillion operations per second. Efficiency 100%

Step 2: Someone writes a compiler that converts C++ into assembly language / processor specific stuff that makes a lot of assumptions and loses a big chunk of efficiency Efficiency 80%

Step 3: A coder like me waltzes in and writes some code that is as optimized as he can possibly manage, but has deadlines etc and knowledge gaps meaning it’s slightly less efficient than optimal Efficiency 75%

Step 4: He then writes it to run on a single core, because the headache of smoothly spreading tasks over all the cores is unbelievable, plus game code doesn’t multithread easily so… Efficiency 25%

Step 5: Because writing a new engine for each game is un-trendy these days, the coder decides to use an off the shelf engine that makes even more assumptions and compromises… Efficiency 15%

Step 6: Coder #2, not knowing the assumptions Coder #1 made when we wrote those handy functions, calls them every frame instead of once… Efficiency 5%

Step 7: The game gets run on a typical desktop PC, with 30 different apps fighting for CPU and RAM, IM clients, P2P stuff, web browsers, email, all that crapware that shipped with the PC, anti-virus scanners, cool desktop widgets that tell you the weather, music streaming as you play… Final Efficiency 3%.


My numbers are wild guesses, but I reckon there is some truth to it all. For inexperienced coders using off the shelf engines probably boosts efficiency. Maybe some engines under some circumstances on some hardware multithreading is more possible. I can’t help[ fantasizing about a PC that absolutely locked everything down in a big way when you launched a fullscreen game. Turned off everything that could possibly use some CPU or RAM and let the game run like an xbox. Maybe that is what steambox will become?

That’s more likely than many programmers learning how to optimize, that’s for sure :(


7 Responses to “Creeping inefficiency”

  1. Metalfusion says:

    So, the real question is: How efficient will GSB2 be?

  2. Bram Stolk says:

    I suspect that C++ OO has a lot to do with it as well, with lots of AoS coding, instead of SoA. Without proper Data Oriented Design, it is hard to keep a processor fed with enough work.

  3. Stropp says:

    There’s also the fact that optimisation should (rightly) be one of the last things that is done on a software project. Given that most coders have a strong desire to see the back end of any project that has run longer than six months, it’s no surprise that optimising the code isn’t done, or if it is it’s just half-arsed.

  4. Leo says:

    The biggest reason is that most AAA are console ports and don’t even marginally tax a a single core.

    The next biggest reason is that console games tend to be rushed/have strict deadlines that means the game is rarely optimized

    Lastly, console gamers are not discerning audience. The netcode in many ports is awful compared to games 15 years ago for christ sake.

    I would take any game from the mid to late 90’s and love to compare the network code against any modern AAA game. Bet we’d see how sloppy/badly engineered multiplayer is in console land.

  5. Ben Hymers says:

    I’d add another big contributing factor to that list: ancient codebases containing cruft from several previous games, and written for older hardware generations. Nobody has time to write a new engine from scratch for each game, and if they did it would be out of date by the time it was finished.

  6. Sniper Sheep says:

    If we talk about CPU only…(no GPU)

    Final Computer Product Efficiency

    Level 1 – High End CPU sitting on a factory self. It has a real world theoretical peak performance -> n mips, n mflops -> 100% Should be able to run all modern games.

    Level 2 – Hardware Integration. What kind of hardware surrounds the CPU? Memory speed, bus speed…etc.

    Level 3 – OS – How efficient is the Operating System? How many background process is it running without user control? How fast are the peripherals communicating with each other? Latency.

    Application Efficiency

    Level 1 – Code – Developer

    Today’s industry standard compilers are efficient. You won’t loose too much just based on compilers alone. Almost everybody working on a commercial product is using high quality compilers. They’re around 90%+ efficient.

    Inefficient code by the programmer. -> Theoretical performance loss is 1-100%

    Games that were originally developed and optimized for another platform with different architecture usually need a complete overhaul. Games ported from Console to PC comes to mind. Different CPU architecture, different compilers etc. Low quality port is inefficient code. -> Theoretical performance loss is 1-100%

    My wild guess is that on the PC market the average performance loss by inefficient code is between 20%-80%

    Level 1b – Special CPU Features – Developer

    What features are compatible or found in other processors that contributes to the maximum peak performance and you would use?

    As a developer you have to make your game as compatible as possible. Your minimum system requirement might include processors that are missing features of the high end processor. You cannot use those features, or you can make the use of those features optional. -> Less effective.

    If you don’t use any exotic features, your properly coded game will scale nicely speed wise with higher frequency, amount of cache etc.

    Level 2 – User

    In a multitasking environment what other necessary/unnecessary processes are running under user control? From Wi-Fi to full fledged applications every background process taxes your system. Theoretical performance loss is 1-100%

    Just my 2 cents…

  7. CdrJameson says:

    Perhaps now that processors aren’t getting much quicker (just more of them) we’ll see more efficient code?