Dziwna różnica wydajności C++?

Question

Po prostu natknąłem się na zmianę, która wydaje się mieć sprzeczne z intuicją konsekwencje wydajności. Czy ktoś może podać wyjaśnienie tego zachowania?

oryginalny kod:

for (int i = 0; i < ct; ++i) { 
    // do some stuff... 

    int iFreq = getFreq(i); 
    double dFreq = iFreq; 

    if (iFreq != 0) { 
     // do some stuff with iFreq... 
     // do some calculations with dFreq... 
    } 
} 

Podczas czyszczenia ten kod podczas „przejściu performance”, postanowiłem przenieść definicję dFreq wewnątrz bloku if, ponieważ był używany tylko wewnątrz if. Istnieje kilka obliczeń związanych z dFreq, więc nie wyeliminowałem go całkowicie, ponieważ pozwala to zaoszczędzić na kosztach wielu konwersji w czasie rzeczywistym z int do double. Nie spodziewałem się żadnej różnicy w wydajności, lub jeśli w ogóle jakiejkolwiek, nieznacznej poprawy. Jednak wydajność spadła o prawie 10%. Zmierzyłem to wiele razy i jest to rzeczywiście zmiana, którą wprowadziłem. Pokazany powyżej fragment kodu wykonuje się wewnątrz kilku innych pętli. Dostaję bardzo spójne przebiegi między przebiegami i mogę zdecydowanie potwierdzić, że zmiana, którą opisuję, zmniejsza wydajność o ~ 10%. Oczekuję, że wydajność wzrośnie, ponieważ konwersja int do double nastąpi tylko wtedy, gdy iFreq != 0.

kod Chnaged:

for (int i = 0; i < ct; ++i) { 
    // do some stuff... 

    int iFreq = getFreq(i); 

    if (iFreq != 0) { 
     // do some stuff with iFreq... 
     double dFreq = iFreq; 
     // do some stuff with dFreq... 
    } 
} 

Może ktoś to wyjaśnić? Używam VC++ 9.0 z/O2. Chcę tylko zrozumieć, o czym tutaj nie mówię.

Answer 1

Należy umieścić konwersję do dFreq natychmiast wewnątrz if() przed robi obliczeń z iFreq. Konwersja może być wykonywana równolegle z obliczeniami całkowitymi, jeśli instrukcja znajduje się dalej w kodzie.Dobry kompilator może być w stanie popchnąć go dalej, a niezbyt dobry może po prostu zostawić go tam, gdzie upadnie. Ponieważ przeniosłeś ją po obliczeniach całkowitych, może nie zostać uruchomiona równolegle z kodem całkowitym, co prowadzi do spowolnienia. Jeśli działa równolegle, może to oznaczać niewielką poprawę lub brak poprawy w zależności od procesora (wydawanie instrukcji FP, której wynik nigdy nie zostanie użyty, będzie miało niewielki wpływ na oryginalną wersję).

Jeśli naprawdę chcesz, aby zwiększyć wydajność, liczba ludzi zrobili odniesienia i pozycjonowanie następujące kompilatory w tej kolejności:

1) ICC - Intel kompilatora 2) GCC - dobre drugie miejsce 3) Wygenerowany przez MSVC kod może być dość słaby w porównaniu do innych.

Możesz także spróbować -O3, jeśli go masz.

Answer 2

Być może wynik getFreq jest przechowywany wewnątrz rejestru w pierwszym przypadku i zapisywany do pamięci w drugim przypadku? Może się również zdarzyć, że spadek wydajności ma związek z mechanizmami CPU jako przepuszczaniem potoków i/lub prognozowaniem rozgałęzień. Można sprawdzić wygenerowany kod zespołu.

Answer 3

Może kompilator optymalizuje go, przyjmując definicję poza pętlą for. kiedy umieścisz go, jeśli optymalizacje kompilatora tego nie robią.

Answer 4

Istnieje prawdopodobieństwo, że ta zmiana spowodowała, że ​​kompilator wyłączył niektóre optymalizacje. Co się stanie, jeśli przeniesiesz deklaracje powyżej pętli?

Answer 5

Po przeczytaniu dokumentu na temat optymalizacji, który stwierdził, że zdefiniowanie zmiennych tuż przed ich użyciem, a nawet wcześniej nie było dobrą praktyką, kompilatorzy mogli zoptymalizować kod zgodnie z tą radą.

Ten artykuł (nieco stary, ale bardzo ważne) powiedzieć (statystyki) coś podobnego: http://www.tantalon.com/pete/cppopt/asyougo.htm#PostponeVariableDeclaration

Answer 6

Spróbuj przenieść definicję dFreq poza pętli for ale zachować zadanie wewnątrz pętli for/if bloku.

Być może tworzenie dFreq na stosie co pętli, wewnątrz if, powoduje problem (chociaż kompilator powinien się tym zająć). Być może regresja w kompilatorze, jeśli dFreq var jest w czterech pętlach utworzonych raz, wewnątrz wewnątrz, jeśli jest tworzony za każdym razem.

double dFreq; 
int iFreq; 
for (int i = 0; i < ct; ++i) 
{ 
    // do some stuff... 

    iFreq = getFreq(i); 

    if (iFreq != 0) 
    { 
     // do some stuff with iFreq... 
     dFreq = iFreq; 
     // do some stuff with dFreq... 
    } 
} 

Answer 7

Łatwo się dowiedzieć. Po prostu weź 20 stackshots powolnej wersji i szybkiej wersji. W wersji powolnej zobaczysz na około dwóch ujęciach, co robi, że nie robi się w szybkiej wersji. Zobaczysz subtelną różnicę w tym, gdzie zatrzymuje się w języku asemblerowym.

Answer 8

To mi wygląda na straganie rurociągu

int iFreq = getFreq(i); 
    double dFreq = iFreq; 

    if (iFreq != 0) { 

pozwala na konwersję podwoi się zdarzyć równolegle z innym kodem od dFreq nie jest używany natychmiast. daje kompilatorowi coś pomiędzy przechowywaniem iFreq i używaniem go, więc ta konwersja jest najprawdopodobniej "wolna" .

Ale

int iFreq = getFreq(i); 

if (iFreq != 0) { 
    // do some stuff with iFreq... 
    double dFreq = iFreq; 
    // do some stuff with dFreq... 
} 

Może być uderzenie stoisko przechowywać/referencyjny po konwersji do podwojenia ponieważ rozpoczęciem korzystania z podwójną wartość od razu.

Nowoczesne procesory mogą wykonywać wiele czynności na cykl zegara, ale tylko wtedy, gdy rzeczy są niezależne. Dwie kolejne instrukcje odnoszące się do tego samego rejestru często powodują przeciągnięcie. Rzeczywista konwersja do podwójnej może zająć 3 zegary, ale wszystkie oprócz pierwszego zegara mogą być wykonane równolegle z inną pracą, pod warunkiem, że nie odnoszą się do wyniku konwersji dla instrukcji lub dwóch.

Kompilatory C++ radzą sobie całkiem nieźle z poleceniami ponownego zamawiania, aby z tego skorzystać, wygląda na to, że zmiana uległa pewnej optymalizacji.

Inną (mniej prawdopodobną) możliwością jest to, że gdy konwersja do wartości zmiennoprzecinkowej była przed gałęzią, kompilator mógł całkowicie usunąć gałąź. Kod bezgałęziowy jest często główną wygraną wydajności w nowoczesnych procesorach.

Interesujące byłoby zobaczyć, jakie instrukcje faktycznie wydał kompilator dla tych dwóch przypadków.