Duff’s Device: loop unrolling for interpreted languages

In 1983, Tom Duff invented a really strange way to use the C language’s switch and case statements for the in code “unrolling” optimization of large loops. As an example, he described a simple loop that copies an array to an output register:

	send(to, from, count)
	register short *to, *from;
	register count;
	{
		do
			*to = *from++;
		while(--count>0);
	}

On every iteration of the loop, in addition to the copy that is being performed, the count variable is decremented and a comparison is done against 0. Duff’s Device allows you to achieve the same result, but with only an 8th of the overhead:

	send(to, from, count)
	register short *to, *from;
	register count;
	{
		register n=(count+7)/8;
		switch(count%8){
		case 0:	do{	*to = *from++;
		case 7:		*to = *from++;
		case 6:		*to = *from++;
		case 5:		*to = *from++;
		case 4:		*to = *from++;
		case 3:		*to = *from++;
		case 2:		*to = *from++;
		case 1:		*to = *from++;
			}while(--n>0);
		}
	}

What happens is that the loop is unrolled 8 times, so each iteration of the loop runs the internal code 8 times over without the comparison. The genius of Duff’s Device is that it takes advantage of the way the C switch/case structure works. The first time through, if the iterations don’t divide evenly by 8, the loop code is executed enough times to equal the remainder of iterations/8. It’s a little bizarre, because the “do” statement occurs within the switch, but there are “case” statements within the “do”. Nevertheless, it’s valid C.

Before someone cries foul, remember that this is only really suitable for speeding up the performance of inner loops when no suitable, better algorithm is available. If you code C, most modern compilers are smart enough to automatically optimize your code and unroll loops for you.

For interpreted languages like PHP or Javascript, however, you sometimes need to do a little optimization on your own if you want to squeeze out some extra performance. Luckily, both languages have a c-style switch statement.

Andy King wrote about a slightly altered version of this loop unrolling algorithm which ditches the switch statement and breaks the normal Duff’s Device into two separate loops, one for the remainder and one for the unrolling. In Javascript, it performs a simple addition loop in only a third of the time of a normal for loop (testVal++ is the normal loop’s interior):

function duffFasterLoop8(iterations) {
  var testVal=0;	
  var n = iterations % 8;
  if (n>0) {
    do 
    {
      testVal++;
    }
    while (--n); // n must be greater than 0 here
  }
    
  n = parseInt(iterations / 8);
  do 
  {
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    testVal++;
  }
  while (--n);
}

It’s not as syntactically clever as Duff’s Device, but it’s a good way to manually unroll an inner loop and get the best performance for your extra effort.

Duff’s Device
Andy King’s Optimizing JavaScript For Execution Speed

4 Responses to Duff’s Device: loop unrolling for interpreted languages

  1. I wonder why these stupid things keep coming up every 5 to 10 years.

    Ever thought about cache behaviour ?
    Or the fact that an “decrease, compare and jump” is basically free ?

    Please take a look at the assembler that gets generated from “Duff’s Device” and then tell me again that it’s a good idea to use it.

    Please you young and innocent out there:
    Forget that you ever saw this, there is a good reason why it has been buried long time ago.
    :)

  2. Anonymous on said:

    function duffFasterLoop8(iterations) {
    var testVal=0;

    for(n = iterations; n > 8; n -= 8)
    {
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    testVal++;
    }

    do
    {
    testVal++;
    }
    while (–n);

    }

  3. Anonymous on said:

    I’m one of those who re-discovered same optimization several years ago. And it works. Benchmarks show real speed improvements. And it probably worked even better in 1983, when C compilers were really bad.
    What about code size and cache issues? As long as code completely fits into L1, who cares?

  4. Shantanu Goel on said:

    Nice explanation. People don’t understand that micro-optimizations are still useful. Not every compiler in the world is gcc-like. You may have to use different compilers for different projects, different devices and many compilers need hand-holding to produce better results, even gcc performs better if you provide more info to it. Here is another article about getting compilers to produce better code for loops:
    http://www.safercode.com/blog/2009/01/27/tweak-your-code-for-speed-unroll-those-loops-part-1.html

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s