Jonathan Blow's home page

John Carmack on Inlined Code

In the years since I wrote this, I have gotten much more bullish about pure functional programming, even in C/C++ where reasonable: http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php

The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).

As an additional confirmation of the point of the article, a couple years later when I was working on the Doom 3 BFG edition release, the exactly predicted off-by-one-frame-of-latency input sampling happened, and very nearly shipped. That was a cold-sweat moment for me . after all of my harping about latency and responsiveness, I almost shipped a title with a completely unnecessary frame of latency.

To make things more complicated, the .do always, then inhibit or ignore. strategy, while a very good idea for high reliability systems, is less appropriate in power and thermal constrained environments like mobile.

John Carmack

September 26, 2014

From: John Carmack

Date: Tue, Mar 13, 2007 at 4:17 PM

Subject: inlining code

This is going to be an unusual email -- I want to talk about coding style. I'm not going to issue any mandates, but I want everyone to seriously consider some of these issues. I'm not talking about petty things like spaces around operators, bracing styles, or pointers by type or variable (although we probably should settle that one), but about larger organization of code. There aren't any silver bullets, but months can be shaved off of a development project with a few percent improvement in productivity.

This email was getting too long, so I am going to follow up with some other thoughts later. I have a lot of general things to discuss, but there is a specific tactical direction that I want to advocate.

A year ago I was involved in a discussion about writing extremely reliable software for aerospace applications, as I have been several times over the years. Typically I am there to rail against the people that talk about using threads and an RTOS for such things, when a simple polled loop that looks like a primitive video game is much more clear and effective. However, this particular discussion brought up a new wrinkle for me:

>Indeed, if memory serves (it's been a while since I read about this)...<br>>The fly-by-wire flight software for the Saab Gripen (a lightweight<br>>fighter) went a step further. It disallowed both subroutine calls and<br>>backward branches, except for the one at the bottom of the main loop.<br>>Control flow went forward only. Sometimes one piece of code had to leave<br>>a note for a later piece telling it what to do, but this worked out well<br>>for testing: all data was allocated statically, and monitoring those<br>>variables gave a clear picture of most everything the software was doing.<br>>The software did only the bare essentials, and of course, they were<br>>serious about thorough ground testing.<br>>No bug has ever been found in the "released for flight" versions of that<br>>code.<br>> Henry Spencer<br>> henry@spsystems.net

Now, a great deal of stuff that goes on in the aerospace industry should not be emulated by anyone, and is often self destructive. Most of you have probably read various popular articles about the development process that produces the space shuttle software, and while some people might think that the world would be better if all software developers were that "careful", the truth is that we would be decades behind where we are now, with no PC's and no public internet if everything was developed at that snail's pace.

This particular anecdote seemed to have some practical value, so I decided to give it a try. The flight control code for the Armadillo rockets is only a few thousand lines of code, so I took the main tic function and started inlining all the subroutines. While I can't say that I found a hidden bug that could have caused a crash (literally...), I did find several variables that were set multiple times, a couple control flow things that looked a bit dodgy, and the final code got smaller and cleaner.

After living with the code in that style for quite some time, I haven't found any drawbacks to it, and I have started applying the general approach to my code at Id. In lots of places there is a choice between organizing code a few ways:

------- style A:

void MinorFunction1( void ) {

void MinorFunction2( void ) {

void MinorFunction3( void ) {

void MajorFunction( void ) {<br>MinorFunction1();<br>MinorFunction2();<br>MinorFunction3();

--------- style B:

void MajorFunction( void )...