Comments on: Efficient C Tips #7 – Fast loops

By: Eric Miller

Eric Miller — Wed, 15 Feb 2012 11:11:16 +0000

You intended for your last example to be incorrect, but it’s incorrect for the wrong reason. It does not initialize lpc.

A fully corrected version of the code would look something like this:

#define DIMOF(a) (sizeof(a)/sizeof(a[0]))

uint8_t bar[10];
uint8_t lpc = DIMOF(bar) – 1;

do
{
bar[lpc] = 0;
} while (–lpc);

By: C Programming Tips | Mechanics, Electronics & Computing

C Programming Tips | Mechanics, Electronics & Computing — Thu, 08 Sep 2011 02:50:17 +0000

[...] Efficient C Tips #7 – Fast loops [...]

By: Krzysztof Wesołowski

Krzysztof Wesołowski — Mon, 29 Aug 2011 01:17:00 +0000

It is actually important to consider “under the hood” things while creating code. However while assembler is first “under the hood” thing, compilers is second.

Real deal is to write code which structure allow optimization. Its really simple for compiler to change counting direction when the only purpose of loop is to execute code multiple times. However much more complex is what you mentioned – addressing using loop counter etc.

I think that the most important place to optimise C code is to fit code to target hardware, like described in comment bzero implementation – it can provide much more gain than simple tweaks every decent compiler can do.

By: Doug

Doug — Tue, 27 Jul 2010 23:45:45 +0000

Thanks for this post! I also started programming in assembly and always prefer to use a count-down loop when possible. Yes, there are places where it doesn’t work but lots of times when it does, and it should be tried first. I’ve been known to use this as an interview question to see how low-level a programmer thinks.

By: Greg Nelson

Greg Nelson — Wed, 24 Feb 2010 20:00:57 +0000

Guess I'm just an "under the hood" kind of guy. My first undergrad CS class had us compile something with -S and look at what came out, I guess I never stopped.I'm a huge fan of loop unrolling. There are also times when rewriting memcpy() is exactly what you want to do. One current application needs to erase 1024 continguous, word aligned bytes MANY times, very fast. Creating a specialized 'bzero' that (1) assumes word alignment, (2) takes a length in words, not bytes, and (3) gives up in disgust if the length isn't a multiple of the unrolling, allowed this to go from a 77us operation to an under 5us operation.Which, to paraphrase what Nigel might say, lets the CPU save 94% of the family joules.

By: Nigel Jones

Nigel Jones — Thu, 28 Jan 2010 12:17:53 +0000

Ashleigh:I completely agree about looking at the generated code. This is a technique I use all the time. Alas to really make use of it you have to understand the instruction set of the target – and this is becoming increasingly rare. Indeed companies are now making a virtue of not having to understand the instruction set / resort to assembly language with their CPU – see Luminary Cortex for an example of this. While I see the appeal of this, divorcing oneself from what's going on under the hood is not a great idea IMHO.

By: ashleigh

ashleigh — Tue, 26 Jan 2010 01:31:01 +0000

Another comment about countdown loops.I have used LOTS of timers, and these are really easy when you have a regular tick going off – in a poor mans round-robin scheduler. A timer is just a byte used to count.Counting down is easy – you test for 0 and when so, the counter has expired – you go do stuff. And its also easy then to set the timer to a special value (UNUSED) which is 255 (0xFF) for byte sized counters. Then you do a test – if the timer is UNUSED, ignore it. Otherwise, decrement and when 0, do stuff.The test against 0xFF is not always very efficient. The test against 0 (just after a decrement) is though.

By: ashleigh

ashleigh — Tue, 26 Jan 2010 01:27:00 +0000

In the case of embedded systems programming (and frequently but not always for big systems), there is nothing to be lost and much to be gained by looking at the generated code.And then THINKING.And then trying a few ideas out.If portability is imperitive, then this approach may not be a good move. If portability is not, then it can save your bacon.I've managed to do 9 hand optimisations on some embedded code that HAD TO FIT in 48K.Each time, I had about 100 bytes of spare space. After each hand optimisation (looking at the generated code and changing the C source), I was able to get the same function and get 1K to 2K of free space to add new features into. Each time I thought "thats it, nothing more can be squeezed from this", and each time, I got more. That means the original approx 48K of code was able to be shrunk to about 35K to 38K, just be looking at the generated code and having a think and a fiddle around. [And I should add - this was with space optimisation at the highest setting on the compiler.]I agree that the CS mantra is "dont look, let the compiler work, if it does not fit get a bigger machine."When you are 2 weeks from producyt shipment and your code is 200 bytes TOO BIG to fit on your embedded micro, you boss will not thank you for parroting the CS lecturers attitude. You have to fix it, and you have to fix it now, and putting in a bigger process will slip delivery 6 months. So you look at the generated code, and you go fixing.When you find a construct like loops, or if-else statements, that can save 2 or 3 or 5 bytes eahc time (and you have a couple of hundred of them) it might take a weeks editing, but all those little tiny savings add up to saving the schedule, and saving your job!

By: Tom Evans

Tom Evans — Sat, 10 Oct 2009 06:55:46 +0000

> I'd be interested to hear from> other readers who have recoded> a loop based on this postingYes, but at least 18 years ago on a 68000, where "int", "short" and "unsigned short" gave quite different results.But NOTHING beats unrolling the loop.Unless the innards of the loop are duplicating a library function like memset() or strchr(), and the ones in the library are able to use tricky CPU instructions.Especially the cache management tricks in a good memcpy() on CPUs that have a data cache.Over the lifetime of one product based on a 40MHz PPC I improved "memcpy()" from 1.6MB/s to 4MB/s (fixing the CPU initialisation, turning caches on), then 8MB/s (copy 32-bits instead of the library byte-at-a-time), then 17MB/s and finally 27MB/s with proper cache handling. The "memcpy" ended up as 146 lines of C and 120 lines of assembler, with more special cases than you'd believe..

By: Nigel Jones

Nigel Jones — Sun, 15 Mar 2009 17:55:00 +0000

While I agree with you that one should use a decent compiler, I’m not sure I agree with much else Konstantin. (I’ll leave for another day whether GCC is a decent compiler). While just about all compilers will recognize that it’s more efficient to count down in the trivial cases that we have used here, I know it is not the case when the body of the loops start getting large. Now your assertion that programmers should not concern themselves with implementation details is IMHO wrong in several ways.1. In the particular circumstances of this example, I know of no incidences where counting down produces worse code than counting up. The converse is not true. Thus my approach is arguably more portable across different architectures.2. The argument that a programmer need not concern himself with the underlying architecture of the CPU is one that is regularly advanced by those with a CS background. Although I admire the purity of the argument, it simply doesn’t stand up to inspection in real time embedded systems. Why? Well the performance of embedded systems is judged by multiple criteria. For example in hard real time systems the correct answer delivered too late is useless. Similarly in portable systems the correct answer delivered using too many Joules is also useless. In fact this whole concept of whether one should code to the target platform is a fascinating topic in its own right. I’ll endeavor to address this in a future posting.In the interim, thanks for joining the debate. I’d be interested to hear from other readers who have recoded a loop based on this posting – and what they found out. If you do post your results, please include the target processor, compiler and optimization settings. Thanks!