What are you favorite low level code optimization tricks?

Question

I know that you should only optimize things when it is deemed necessary. But, if it is deemed necessary, what are your favorite low level (as opposed to algorithmic level) optimization tricks.

For example: loop unrolling.

Answer 1

gcc -O2

Compilers do a lot better job of it than you can.

Answer 2

++i can be faster than i++, because it avoids creating a temporary.

Whether this still holds for modern C/C++/Java/C# compilers, I don't know. It might well be different for user-defined types with overloaded operators, whereas in the case of simple integers it probably doesn't matter.

But I've come to like the syntax... it reads like "increment i" which is a sensible order.

Answer 3

Picking a power of two for filters, circular buffers, etc.

So very, very convenient.

Answer 4

Counting down a loop. It's cheaper to compare against 0 than N:

for (i = N; --i >= 0; ) ...

Shifting and masking by powers of two is cheaper than division and remainder, / and %

#define WORD_LOG 5
#define SIZE (1 << WORD_LOG)
#define MASK (SIZE - 1)

uint32_t bits[K]

void set_bit(unsigned i)
{
    bits[i >> WORD_LOG] |= (1 << (i & MASK))
}

Edit

(i >> WORD_LOG) == (i / SIZE) and
(i & MASK) == (i % SIZE)

because SIZE is 32 or 2^5.

Answer 5

recycling the frame pointer all of a sudden

pascal calling convention

rewrite stack frame tail call optimization (although sometimes messes with above)

vfork() rather than fork() before exec()

and one I'm still looking for an excuse to use: data driven code generation at runtime

Answer 6

Inspect the compiler's output, then try to coerce it to do something faster.

Answer 7

Why, bit twiddling hacks, of course!

Answer 8

Allocating with new on a pre-allocated buffer using C++'s placement new.

Answer 9

Using template metaprogramming to calculate things at compile time instead of at run-time.

Answer 10

One of the most useful in scientific code is to replace pow(x,4) with x*x*x*x. Pow is almost always more expensive than multiplication. This is followed by

  for(int i = 0; i < N; i++)
  {
    z += x/y;
  }

to

  double denom = 1/y;
  for(int i = 0; i < N; i++) 
  {
    z += x*denom;
  }

But my favorite low level optimization is to figure out which calculations can be removed from a loop. Its always faster to do the calculation once rather than N times. Depending on your compiler, some of these may be automatically done for you.

Answer 11

In SQL, if you only need to know whether any data exists or not, don't bother with COUNT(*):

SELECT 1 FROM table WHERE some_primary_key = some_value

If your WHERE clause is likely return multiple rows, add a LIMIT 1 too.

(Remember that databases can't see what your code's doing with their results, so they can't optimise these things away on their own!)

Answer 12

I've found that changing from a pointer to indexed access may make a difference; the compiler has different instruction forms and register usages to choose from. Vice versa, too. This is extremely low-level and compiler dependent, though, and only good when you need that last few percent.

E.g.

for (i = 0;  i < n;  ++i)
    *p++ = ...; // some complicated expression

vs.

for (i = 0;  i < n;  ++i)
    p[i] = ...; // some complicated expression

Answer 13

Years ago with a not-so-smart compilier, I got great mileage from function inlining, walking pointers instead of indexing arrays, and iterating down to zero instead of up to a maximum.

When in doubt, a little knowledge of assembly will let you look at what the compiler is producing and attack the inefficient parts (in your source language, using structures friendlier to your compiler.)

Answer 14

I wouldn't necessarily call it a low level optimization, but I have saved orders of magnitude more cycles through judicious application of caching than I have through all my applications of low level tricks combined. Many of these methods are applications specific.

• Having an LRU cache of database queries (or any other IPC based request).
• Remembering the last failed database query and returning a failure if re-requested within a certain time frame.
• Remembering your location in a large data structure to ensure that if the next request is for the same node, the search is free.
• Caching calculation results to prevent duplicate work. In addition to more complex scenarios, this is often found in if or for statements.

CPUs and compilers are constantly changing. Whatever low level code trick that made sense 3 CPU chips ago with a different compiler may actually be slower on the current architecture and there may be a good chance that this trick may confuse whoever is maintaining this code in the future.

Answer 15

precalculating values.

For instance, instead of sin(a) or cos(a), if your application doesn't necessarily need angles to be very precise, maybe you represent angles in 1/256 of a circle, and create arrays of floats sine[] and cosine[] precalculating the sin and cos of those angles.

And, if you need a vector at some angle of a given length frequently, you might precalculate all those sines and cosines already multiplied by that length.

Or, to put it more generally, trade memory for speed.

Or, even more generally, "All programming is an exercise in caching" -- Terje Mathisen

Some things are less obvious. For instance traversing a two dimensional array, you might do something like

    for (x=0;x<maxx;x++)
       for (y=0;y<maxy;y++)
          do_something(a[x,y]);

You might find the processor cache likes it better if you do:

   for (y=0;y<maxy;y++)
       for (x=0;x<maxx;x++)
           do_something(a[x,y]);

or vice versa.

Answer 16

Don't do loop unrolling. Don't do Duff's device. Make your loops as small as possible, anything else inhibits x86 performance and gcc optimizer performance.

Getting rid of branches can be useful, though - so getting rid of loops completely is good, and those branchless math tricks really do work. Beyond that, try never to go out of the L2 cache - this means a lot of precalculation/caching should also be avoided if it wastes cache space.

And, especially for x86, try to keep the number of variables in use at any one time down. It's hard to tell what compilers will do with that kind of thing, but usually having less loop iteration variables/array indexes will end up with better asm output.

Of course, this is for desktop CPUs; a slow CPU with fast memory access can precalculate a lot more, but in these days that might be an embedded system with little total memory anyway…

Answer 17

Jon Bentley's Writing Efficient Programs is a great source of low- and high-level techniques -- if you can find a copy.

Answer 18

Eliminating branches (if/elses) by using boolean math:

if(x == 0)
    x = 5;

// becomes:

x += (x == 0) * 5;
// if '5' was a base 2 number, let's say 4:
x += (x == 0) << 2;

// divide by 2 if flag is set
sum >>= (blendMode == BLEND);

This REALLY speeds things out especially when those ifs are in a loop or somewhere that is being called a lot.

Answer 19

Liberal use of __restrict to eliminate load-hit-store stalls.

Answer 20

The one from Assembler:

xor ax, ax

instead of:

mov ax, 0

Classical optimization for program size and performance.

Answer 21

Optimizing cache locality - for example when multiplying two matrices that don't fit into cache.

Answer 22

Rolling up loops.

Seriously, the last time I needed to do anything like this was in a function that took 80% of the runtime, so it was worth trying to micro-optimize if I could get a noticeable performance increase.

The first thing I did was to roll up the loop. This gave me a very significant speed increase. I believe this was a matter of cache locality.

The next thing I did was add a layer of indirection, and put some more logic into the loop, which allowed me to only loop through the things I needed. This wasn't as much of a speed increase, but it was worth doing.

If you're going to micro-optimize, you need to have a reasonable idea of two things: the architecture you're actually using (which is vastly different from the systems I grew up with, at least for micro-optimization purposes), and what the compiler will do for you.

A lot of the traditional micro-optimizations trade space for time. Nowadays, using more space increases the chances of a cache miss, and there goes your performance. Moreover, a lot of them are now done by modern compilers, and typically better than you're likely to do them.

Currently, you should (a) profile to see if you need to micro-optimize, and then (b) try to trade computation for space, in the hope of keeping as much as possible in cache. Finally, run some tests, so you know if you've improved things or screwed them up. Modern compilers and chips are far too complex for you to keep a good mental model, and the only way you'll know if some optimization works or not is to test.

Answer 23

In addition to Joshua's comment about code generation (a big win), and other good suggestions, ...

I'm not sure if you would call it "low-level", but (and this is downvote-bait) 1) stay away from using any more levels of abstraction than absolutely necessary, and 2) stay away from event-driven notification-style programming, if possible.

1. If a computer executing a program is like a car running a race, a method call is like a detour. That's not necessarily bad except there's a strong temptation to nest those things, because once you're written a method call, you tend to forget what that call could cost you.

2. If your're relying on events and notifications, it's because you have multiple data structures that need to be kept in agreement. This is costly, and should only be done if you can't avoid it.

In my experience, the biggest performance killers are too much data structure and too much abstraction.

Answer 24

I was amazed at the speedup I got by replacing a for loop adding numbers together in structs:

const unsigned long SIZE = 100000000;

typedef struct {
    int a;
    int b;
    int result;
} addition;

addition *sum;

void start() {
    unsigned int byte_count = SIZE * sizeof(addition);

    sum = malloc(byte_count);
    unsigned int i = 0;

    if (i < SIZE) {
        do {
            sum[i].a = i;
            sum[i].b = i;
            i++;
        } while (i < SIZE);
    }    
}

void test_func() {
    unsigned int i = 0;

    if (i < SIZE) { // this is about 30% faster than the more obvious for loop, even with O3
        do {
            addition *s1 = &sum[i];
            s1->result = s1->b + s1->a;
            i++;
        } while ( i<SIZE );
    }
}

void finish() {
    free(sum);
}

Why doesn't gcc optimise for loops into this? Or is there something I missed? Some cache effect?