{"id":47965,"date":"2019-09-12T06:00:46","date_gmt":"2019-09-12T10:00:46","guid":{"rendered":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=47965"},"modified":"2019-09-12T08:56:08","modified_gmt":"2019-09-12T12:56:08","slug":"game-programming-vexations-part-3-the-dominance-of-c","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=47965","title":{"rendered":"Game Programming Vexations Part 3: The Dominance of C++"},"content":{"rendered":"

C++ is the main language of game development. This is changing slowly as indies embrace other languages, but in the AAA space C++ is still overwhelmingly dominant. C++ is descended from – and is very similar to – the language C. First created in 1972, C is just one year younger than I am. It was devised for the world of the 1970s. It was targeted at the hardware of the 1970s, and was originally intended for writing operating systems.<\/p>\n

This seems crazy, doesn’t it? Writing operating systems for Nixon-era mainframes is so vastly different from building AAA games in 2019 that it’s like we’re using coal-fired steam engines to go to the moon. Sure, the steam engine has been modernized a bit, but there are still conventions built into the language that don’t make a lot of sense in the world of 2019. The fact remains that somewhere underneath all those rocket engines and silver wings is a chugging steam engine.<\/p>\n

C++ certainly has language features not available in C. C++ has classes, inheritance, operator overloading, and a bunch of other slick ways of expressing complex solutions in code. Those are nice, but none of those things uniquely<\/b> address challenges faced in games programming. We could, in an alternate universe, use a different sort of language with a different set of features.<\/p>\n

It’s not like this industry is incapable of evolution! Studios have changed game engines, and game engines have changed what graphics API they favorOn the PC side, this boils down to DirectX vs. OpenGL, with third-party candidate Vulkan landing a few recent wins.<\/span>. Our tools are different, the target hardware is different, the operating systems are different, and the performance challenges have changed numerous times. Rendering technology has gone through at least two major revolutions. First there was the jump from software rendering to using dedicated graphics hardware, and then another jump when we added the ability to program that graphics hardware using shaders<\/a>. Over the last 30 years we’ve changed every single thing about game development except<\/b> the language!<\/p>\n

<\/p>\n

So Why are we still using this language?<\/h3>\n

Sure, I can take this thing to the moon... as long as you build me a track between here and there.<\/div>
Sure, I can take this thing to the moon... as long as you build me a track between here and there.<\/div><\/p>\n

Some people claim that we’re stuck with this language due to industry inertia. We use this language because we’ve always used this language. We use it because that’s what the programmers study, and programmers study it because that’s what everyone uses. Four years ago I made the case that the dominance of C++ is due to the following factors<\/a>:<\/p>\n

    \n
  1. Lots of libraries.<\/b> There are tons and tons of C++ toolkits, libraries, and code snippets floating around in the wild. Do you need a sound library? Font loading? Access to rendering hardware? Support for gaming controllers? You don\u2019t need to write that code yourself, because there\u2019s a really good chance that someone else has already solved the problem and provided the source code for free. Of course, adding their code to your project is often a lot harder than it ought to be, but spending six hours pulling out your hair playing \u201cdependency scavenger hunt\u201d is faster than writing everything from scratch, even if it is a dumb miserable way to spend an evening.<\/li>\n
  2. Lots of programmers.<\/b> Since C++ is the big important language, everyone learns it. Which makes it easy to hire people to work on your project.<\/li>\n
  3. Lots of help.<\/b> Yes, answers to forum questions often take the form of abusive condescension and nerd peacocking, but at least a C++ programmer can get their question answered after their tag-team humiliation. If you\u2019re using one of the more obscure languages, then you might not get any answer at allYou’ll still get mocked, though. Mostly by jackasses asking, “Why didn’t you use C?”<\/span>.<\/li>\n
  4. No dominant alternative.<\/b> It would be one thing if there was another language out there to play Pepsi to C++ Coke, or could be the Apple to the C++ Windows. But there\u2019s no clear contender. Java is good for some tasks, Python is good for others, but none of the challengers works as a broad general-purpose language. And that\u2019s fine. There\u2019s lot of value in specialization. But that focus helps drive the C++ feedback loop of ubiquity.<\/li>\n<\/ol>\n

    I’m still confident that’s all true, but after four years I’d like to argue with my past self and suggest that this industry inertia can’t be the full<\/b> reason for why C++ is so deeply entrenched.<\/p>\n

    The Lie of Simplicity<\/h3>\n

    This image will make sense in about three paragraphs.<\/div>
    This image will make sense in about three paragraphs.<\/div><\/p>\n

    PC hardware is usually presented as a processor and a pile of memory. When a program is run, the processor makes changes to the contents of the memory, and you get some sort of output. On this site, I describe programs this way all the time. Sadly, this is a gross over-simplification. To understand why C++ is still dominant, we need to look at how the hardware is really<\/i> constructed and what it’s really<\/i> doing.<\/p>\n

    What’s actually going on inside of that humming box is that you’ve got a whole bunch of processors all bundled together in a single CPU housing. We call these separate processors “cores”. Those cores don’t make changes to memory directly. Instead, blocks of memory must be copied to a smaller pool of memory called the L2 cache. From there it’s copied to an even smaller<\/b> pool of memory called the L1 cache. This L1 cache is actually inside that CPU housing with the cores. This is the only memory that the cores can manipulate directly. If the processor makes some changes to memory, then the altered block is copied back out through the layers and is stored in main memory.<\/p>\n

    Let’s say you’re a core. The L1 cache is your tiny workbench right in front of you. You can examine bits of memory on the bench. You can compare them, perform arithmetic, and you can make changes to the contents of the memory. Sometimes you need a chunk of memory that you don’t see in front of you. When this happens, then hopefully what you need is stored in the little shed just outside, which is your L2 cache. If the required item isn’t stored there, then you need to jump in your forklift and trundle all the way to the other side of the campus. You need to drive all the way to the particular warehouse that has the stuff you need. Go inside, find the pallet<\/a> that holds the data you’re looking for, and drive it all the way back to your shed. Then take the items you need off the pallet and put them on your workbench so you can get back to work.<\/p>\n

    This is just the tip of the iceberg. There’s also some parallelism that you can take advantage of if you understand the hardware. A single core can handle multiple operations at the same time, provided you structure your operations properly. If you have the variables A and B and you need to modify them independently of each other, then it’s much faster to order your code so that you change A, then B, then A again, then B again. If you simply modify A twice and followed by B twice, then you’ll miss out on some of the potential performance gains.<\/p>\n

    Disclaimer: I’ve never done any real programming at this level. Above is how it’s been described to me by people with more knowledge of programming close to the metal. Even the above is a pretty big simplification of what’s going on, but we’re basically at the edge of my knowledge at this point and I hesitate to add more.\u00a0<\/i><\/p>\n

    Of course, maybe the compiler will help you out and re-order your operations. Maybe it won’t. Do you know how to make sure it does the right thing? Do you know how to check? Do you know what kind of performance gains you’re chasing and if it’s worth your time?<\/p>\n

    This thing where you need to drive to the warehouse is called a “cache miss”, and it can have an immense impact on performance. If you want more detail, this article<\/a> has some great information on when you’ll run into a cache miss and should be approachable to non-coders. I’ve never been able to find any hard numbers on the overall cost of a cache miss, but developer Mike ActonFormerly of Insomniac games. Currently working at Unity.<\/span> throws around the figure of “200 processor cycles”. That’s on the PlayStation 4 hardware, but I’m willing to bet that’s in the same ballpark as the rival consoles and the PC. 200 processor cycles is crazy expensive, and means a cache miss is one of the most expensive things that can happen to your program.<\/p>\n

    And it’s completely invisible in the code!<\/p>\n

    Can’t the Compiler do it for Me?<\/h3>\n

    Can the compiler optimize my code for me? And if so, can it just write the code for me? This job is hard.<\/div>
    Can the compiler optimize my code for me? And if so, can it just write the code for me? This job is hard.<\/div>
    \nI’ll be honest, I don’t enjoy messing with this stuff. I like thinking about the hardware as a simplistic CPU and a magical pool of memory. Worrying about the size of the L1 cache and the fetch timing is when programming stops being fun and starts feeling like accounting. It’s hard and annoying and adds an unwelcome layer of complexity to code. I tend to think of this business with cache limits as “intrusive” and I’d rather let the compiler handle it for me. In fact,     during my Good Robot series you can see me advocating a linked list<\/a> without giving any thought<\/b> to how every single entry is likely to trigger a cache missTo be fair, I was currently being distracted by something even slower.<\/span>. That’s silly, and blunders like that would get me bounced out the door of a serious AAA studios engine teamUnless it was Bethesda Softworks, where they’d probably put me in charge of engine optimization for Gamebryo.<\/span>.<\/p>\n

    I’m not the only one averse to thinking about the actual physical limitations of the hardware. If you poke around you’ll see coders being pennywise and pound foolish with processor cycles. You’ll see advice like:<\/p>\n