Pusta pętla jest wolniejsza od niepustej w C

Zakładając, że Twój kod używa 32-bitowego typu integer int (co prawdopodobnie robi Twój system), nic nie może być określone z twojego kodu. Zamiast tego wykazuje nieokreślone zachowanie.

foo.c:5:5: error: first parameter of 'main' (argument count) must be of type 'int'
int main (char argc, char * argv[]) {
    ^
foo.c:13:26: warning: overflow in expression; result is 2147483647 with type 'int' [-Winteger-overflow]
    for (i = 0; i<(1<<31)-1; i++);
                         ^
foo.c:19:26: warning: overflow in expression; result is 2147483647 with type 'int' [-Winteger-overflow]
    for (i = 0; i<(1<<31)-1; i++) {
                         ^

Spróbujmy to naprawić:

#include <stdint.h>
#include <stdio.h>
#include <time.h>
#include <limits.h>

int main (int argc, char * argv[]) {
    time_t begin, end;
    uint64_t i;
    double total_time, free_time;
    int A = 1;
    int B = 1;

    begin = clock();
    for (i = 0; i<INT_MAX; i++);
    end = clock();
    free_time = (double)(end-begin)/CLOCKS_PER_SEC;
    printf("%f\n", free_time);

    begin = clock();
    for (i = 0; i<INT_MAX; i++) {
        A += B%2;
    }
    end = clock();
    free_time = (double)(end-begin)/CLOCKS_PER_SEC;
    printf("%f\n", free_time);

    return(0);
}

Spójrzmy teraz na wyjście asemblera tego kodu. Osobiście uważam, że montaż wewnętrzny LLVM jest bardzo czytelny, więc zamierzam to pokazać. Wyprodukuję go przez running:

clang -O3 foo.c -S -emit-llvm -std=gnu99

Oto odpowiednia część wyjścia (główny funkcja):

define i32 @main(i32 %argc, i8** nocapture readnone %argv) #0 {
  %1 = tail call i64 @"\01_clock"() #3
  %2 = tail call i64 @"\01_clock"() #3
  %3 = sub nsw i64 %2, %1
  %4 = sitofp i64 %3 to double
  %5 = fdiv double %4, 1.000000e+06
  %6 = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), double %5) #3
  %7 = tail call i64 @"\01_clock"() #3
  %8 = tail call i64 @"\01_clock"() #3
  %9 = sub nsw i64 %8, %7
  %10 = sitofp i64 %9 to double
  %11 = fdiv double %10, 1.000000e+06
  %12 = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), double %11) #3
  ret i32 0
}

Zauważ, że nie mażadnych operacji pomiędzy wywołaniami clock() dlaw obu przypadkach . Więc oba są skompilowane do dokładnie tego samego .

ta odpowiedź zakłada, że już zrozumiałeś i zająłeś się doskonałymi punktami dotyczącymi niezdefiniowanego zachowania sharth w swojej odpowiedzi . Zwraca również uwagę na triki, które kompilator może wykonywać na Twoim kodzie. Należy podjąć kroki, aby upewnić się, że kompilator nie rozpoznaje całej pętli jako bezużytecznej. Na przykład zmiana deklaracji iteratora na volatile uint64_t i; uniemożliwi usunięcie pętli, a volatile int A; zapewni, że druga pętla faktycznie wykona więcej pracy niż najpierw. Ale nawet jeśli zrobisz to wszystko, nadal możesz odkryć, że:

Kod póĺşniej w programie moĹźe wykonaÄ ‡ szybciej niĹź wczeĹ " niejszy kod.

Funkcja biblioteki clock() mogła spowodować błąd icache po odczytaniu timera i przed powrotem. Spowodowałoby to dodatkowy czas w pierwszym mierzonym przedziale. (W przypadku późniejszych wywołań kod jest już w pamięci podręcznej). Jednak efekt ten będzie malutki, z pewnością za mały, aby clock() zmierzyć, nawet jeśli był to błąd strony / align = "left"/ Losowe przełączniki kontekstowe mogą dodawać do każdego przedziału czasowego.

Co ważniejsze, masz procesor i5, który ma dynamiczne Taktowanie. Kiedy program rozpoczyna wykonywanie, częstotliwość taktowania jest najprawdopodobniej niska, ponieważ procesor był bezczynny. Samo uruchomienie programu sprawia, że procesor nie jest już bezczynny, więc po krótkim opóźnieniu Prędkość zegara wzrośnie. Stosunek częstotliwości zegara procesora bezczynnego do Turboboostowanego może być znaczący. (Na moim ultrabooku Haswell i5-4200U, pierwszy mnożnik wynosi 8, a drugi 26, dzięki czemu kod startowy działa mniej niż 30% tak szybko, jak późniejszy kod! "Skalibrowane" pętle do implementacji opóźnień to straszny pomysł na nowoczesnych komputerach!)

Włączenie fazy rozgrzewki (wielokrotne uruchamianie benchmarka i wyrzucanie pierwszego wyniku) dla bardziej precyzyjnego pomiaru czasu jest nie tylko dla zarządzanych frameworków z kompilatorami JIT!

Jestem w stanie odtworzyć to z GCC 4.8.2-19ubuntu1 bez optymalizacji:

$ ./a.out 
4.780179
3.762356

Oto pusta pętla:

0x00000000004005af <+50>:    addq   $0x1,-0x20(%rbp)
0x00000000004005b4 <+55>:    cmpq   $0x7fffffff,-0x20(%rbp)
0x00000000004005bc <+63>:    jb     0x4005af <main+50>

A oto niepuste:

0x000000000040061a <+157>:   mov    -0x24(%rbp),%eax
0x000000000040061d <+160>:   cltd   
0x000000000040061e <+161>:   shr    $0x1f,%edx
0x0000000000400621 <+164>:   add    %edx,%eax
0x0000000000400623 <+166>:   and    $0x1,%eax
0x0000000000400626 <+169>:   sub    %edx,%eax
0x0000000000400628 <+171>:   add    %eax,-0x28(%rbp)
0x000000000040062b <+174>:   addq   $0x1,-0x20(%rbp)
0x0000000000400630 <+179>:   cmpq   $0x7fffffff,-0x20(%rbp)
0x0000000000400638 <+187>:   jb     0x40061a <main+157>

Wstawmy nop w pustej pętli:

0x00000000004005af <+50>:    nop
0x00000000004005b0 <+51>:    addq   $0x1,-0x20(%rbp)
0x00000000004005b5 <+56>:    cmpq   $0x7fffffff,-0x20(%rbp)
0x00000000004005bd <+64>:    jb     0x4005af <main+50>

Teraz biegną równie szybko:

$ ./a.out 
3.846031
3.705035

Wyobrażam sobie, że to pokazuje znaczenie wyrównania, ale obawiam się, że nie mogę dokładnie powiedzieć, jak: /