OSDev.org

bewing wrote:

Wave wrote: Can you explain to me why that is? I always thought counting up would be faster because add is faster than sub, but the x86 has the loop instruction that subs automatically. It is however slower than sub cmp jmp anyways.

All CPUs have the same basic set of flags to test on, when it comes to arithmetic operations. Carry, Zero, Sign, Overflow. Immediately after an arithmetic opcode, you can sometimes test them, and get a useful result.

bewing wrote:

skyking wrote: you don't save that clock cycle on a modern compiler

It is not always wise to count on the compiler to save your @$$ from crappy coding. And in any case, programmers often DO use the index inside the loop, and then the compiler won't touch the code. But you can still code the loop to count up or down.
It is also not wise to look at "how fast some current CPU performs this opcode vs. that one" -- all opcodes are tending toward the limit of 1 opcode per calculation cycle. It is wisest to code for that.

void loop(int* p, int n, int x)
{
	int j, k;

	for( j=0; j<n; j++ )
	{
		p[5*j] = x;
	}
}

void loop(int* p, int n, int x)
{
	int j = n;
	p = p+5*n;

	do
	{
		*p = x;
		p-=5;
	} while( --j>=0 );
}

You're example saved 2% execution time.

piranha wrote: So.....if you save the time, then why keep arguing over this?

piranha wrote: And, again I must ask (as I'm a little confused), who cares? 2% time saved. Woopie.

skyking wrote:Btw I tested to use your example from C source:

#include <stdlib.h>
#include <assert.h>

void loop_init( int * p, int n, int x )
{
    size_t i;
    for ( i = 0; i < n; ++i )
    {
        *p = x;
        p += 5;
    }
}

void loop_up( int * p, int n, int x )
{
    size_t i;
    for ( i = 0; i < n; ++i )
    {
        *p = x;
        p += 5;
    }
}

void loop_down( int * p, int n, int x )
{
    size_t i;
    for ( i = n; i > 0; --i )
    {
        *p = x;
        p += 5;
    }
}

int main()
{
    size_t limit = 25*1024*1024;
    int * p = (int *)malloc( limit * sizeof( int ) );
    assert( p != NULL );
    int i;
    loop_init( p, limit, 42 );
    for ( i = 0; i < 1000; ++i )
        loop_up( p, limit, 42 );
    for ( i = 0; i < 1000; ++i )
        loop_down( p, limit, 42 );
    return 0;
}

$ gcc -pg test.c
$ ./a.out
$ gprof a.out | head
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 50.28     81.94   81.94      1000    81.94    81.94  loop_up
 50.10    163.58   81.65      1000    81.65    81.65  loop_down
...

• Optimization settings (-O0, -O2) had no measurable influence on results,
• loop_down() was faster than loop_up() by anywhere from 0.12% to 0.85%.

bewing wrote:*sigh* The particular example I happened to code, happened to use a memory store operation inside the loop. As you have now discovered, memory store operations (on average) do not happen in one clock cycle.
So the loops were not really 5 clock cycles vs. four. In fact, you seem to have determined that on average, it was 50 vs. 49. So this particular memory store operation seems to take about 45 times as long as a register operation on average.
The savings depend on the tightness of the loop, as I said. If the loop that I had ccded had only used register operations, and no memory operations at all, then the saving would have more closely approached 20%.

And Wave -- if you are truly convinced that addition is (and always will be) faster than subtraction, you can count UP from -N to 0, of course. You'd have to put a lot of explanations in your code, as to why you were doing such a crazy thing, of course.