A problem in the for loop cannot be underestimated

For (INT I = 1; I <= 100; I ++)

As a programmer, we like to use this for loop.

However, it implies an important issue.

Too many programming experiences may lead to some misunderstandings in our thinking. In the for loop above, because we have paid more attention to the content in the for loop body in the past many programming experiences, as a result, we almost ignored the existence of the small I. It played a "small role" as the counter, and we ignored it. But we do not know that its "amount of meals" is not small ~

#include<stdio.h>#include<time.h>int main(){    int temp;    /********************************/    temp=clock();    for(int i=1;i<=100;i++);    printf("%d\n",clock()-temp);    /********************************/    temp=clock();    for(int i=1;i<=1000000000;i++);    printf("%d\n",clock()-temp);    /********************************/    return 0;}

The program execution result is:

0

3000

In this case, the execution time consumed by the small I is also considerable. Some new Programmers think that the execution time of the program is determined by the number of cycles. In this way, the above program seems to be correct, but it is not essential. Anyone who knows programming a little knows that the execution time of a program is determined by the number of operations of the program. Obviously, addition and subtraction are faster than multiplication and division.

If you think that the execution time is determined by the number of cycles, you can look at the following procedure:

#include<stdio.h>#include<time.h>int main(){    int n,temp;    /********************************/    temp=clock();    n=1;    for(int i=1;i<=100000000;i++)    {        n++,n--;        n++,n--;        n++,n--;        n++,n--;        n++,n--;        n++,n--;        n++,n--;        n++,n--;        n++,n--;        n++,n--;    }    printf("%d\n",clock()-temp);    /********************************/    temp=clock();    n=1;    for(int i=1;i<=150000000;i++)n++,n--;    printf("%d\n",clock()-temp);    /********************************/    return 0;}

Program Execution result:

6291

901

The former has 0.1 billion cycles, and the latter has 0.1 billion cycles, but the latter is faster, because the former has many computations. In-depth analysis, the number of addition and subtraction operations of the former is about 100000000 + 100000000*20 = 2100000000, that is, 2.1 billion, and the ratio (I <= 100000000) is 0.1 billion; the number of addition and subtraction operations in the latter is 150000000 + 150000000*2 = 450000000, that is, 0.4 billion million times, and the ratio (I <= 150000000) is 0.1 billion 50 million. The former has more than 1.6 billion million addition and subtraction times than the latter, and the latter has more than comparison times than the former, which may vary depending on the data size.

In any case, on the one hand, we should recognize the factors that determine the execution time, and on the other hand, we should not ignore the role and consumption of small I in the for loop, especially when I is embedded in a L2 loop.

I have done an algorithm question before, And my program will run for 4 s, while the program I optimized for me will only run for less than 1 s, but I still cannot find the reason, because the number of accumulated values in the formula is the same, my cycle is N * SQRT (n), and his cycle is N * lg (n ). At that time, I only paid attention to the data accumulation in the formula, that is, I only paid attention to the content in the loop body, and I did addition even if I was ignored, especially in a layer-2 loop with a data volume of up to 0.5 million, the impact of small I is highlighted, the difference between me and my classmates is that the number of cycles is different (the accumulation in the formula must be the same, otherwise the results will be different and incorrect ). So it seems that sometimes it is necessary to control the number of cycles of the program. In the case of the same algorithm, especially for multi-layer loop programs, reducing the number of cycles can lead to unexpected benefits.

a problem in the for loop that cannot be underestimated