7 Billion Humans – Optimization Tips

Some tips for optimizing your solutions.

General remarks

Except for the more or less trivial cases, your solutions for optimized speed and for optimized instruction count will look different. Sometimes very different. My approach is to first solve the puzzle, then copy the solution over to one of the other program tabs and then optimize it for one of the goals. Always keep in mind that when you’re optimizing for one of them, the other one doesn’t matter at all. Don’t try to subconsciously optimize both speed and count.

Optimizing for instruction count

First, don’t overlook that the instruction count can be seen left to the actual instructions. No surprises here (unlike with the program speed).

If only…
Every if statement counts as a single instruction, no matter how long and complicated it is. So do query as many things as useful in your if. Maybe you can spare something else by these, e.g. a second if?

Making sacrifices
There’s seven billions of them, and they are not needed anymore anyway…! If the level instruction doesn’t say anything else explictly, feel free to let every human expect a last one die. Spare the instruction needed to spare a human.

Embrace errors
This is not about recommending to try out what you can think of, even if it will probably fail – which I totally do. I’m thinking about the little errors. Dropping something although you haven’t got anything to drop? Results in an ugly speech bubble and (probably) takes lots of time, right? Right, but we’re not here to save time. Or bubbles. If it saves you a statement, like an if, just do it.

Do not initialize
Contrary what you are told in real world programming – for a reason -, you might not want to initialize memory sometimes. You don’t need to set it to five and count down to zero. Just add on it and compare it to five instead.

Concise statements
Something I might have been the only one to overlook: If you’ve got a position in memory, you don’t need to walk there and afterwards pickup/giveto or whatever you want there. You can pass the memory directly to the pickup/giveto instruction. Gave me some headaches, so I’m writing this to make sure you will not get these.

Optimizing for speed

The time your program needs to run is harder to predict than the number of instructions. If it’s not fast enough, just watching it run can help: What is happening too slow? Where are the humans waiting for something?

Math is hard
Contradictory to what I expected, in 7 Billion Humans these humans seem to move fast compared to the calculations. But then… it’s humans doing the calculations, so I guess this is to be expected? You probably want to avoid too many calculations.

Inner loops
Now this is just like real world program optimizing: If you want a program to be fast, assure that the inner loops running most often are fast. Mind that you’re not optimizing for count of instuctions here, so an extra if instruction creating a very close loop (check – single instruction – jump – check again) might help your humans getting their work done faster.

Do repeat yourself
If nothing else helps, “loop unrolling” might help. So if you know the number oof times something will be done, you can write it down just as many times instead of having some if-jump construction. Tomorrow Corporation assured for Human Resource Machine that loop unrolling was never needed (except one obvious case as far as I remember) to meet the optimization requirements. I guess the same is true for 7 Billion Humans. Still, it might be a last resort. On the other hand… it is tedious! You might want to do it in an external editor with better copy/paste capabilities if you want to use this technique.

What am I doing here?!?
The most important speedup possibility in real programs is not about the small things, it’s about changing the algorithm. Is the one you’re using the fastest one? Is it at least close to the optimization goal?