Czy poziom optymalizacji -O3 jest niebezpieczny w g ++?

Słyszałem z różnych źródeł (choć głównie od mojego kolegi), że kompilacja z poziomem optymalizacji -O3g ++ jest w jakiś sposób „niebezpieczna” i ogólnie należy jej unikać, chyba że okaże się to konieczne.

Czy to prawda, a jeśli tak, to dlaczego? Czy powinienem się trzymać -O2?

We wczesnych dniach gcc (2.8 itd.) Oraz w czasach egcs i redhat 2.96-O3 bywał czasem dość błędny. Ale to już ponad dziesięć lat temu, a -O3 niewiele różni się od innych poziomów optymalizacji (w buggyness).

Zwykle jednak ujawnia przypadki, w których ludzie polegają na nieokreślonym zachowaniu, z powodu bardziej ścisłego polegania na regułach, a zwłaszcza narożnych przypadkach języka (języków).

Osobiście, od wielu lat prowadzę oprogramowanie produkcyjne w sektorze finansowym z opcją -O3 i nie spotkałem się jeszcze z błędem, którego nie byłoby, gdybym użył opcji -O2.

Według popularnego popytu, tutaj dodatek:

-O3, a zwłaszcza dodatkowe flagi, takie jak -funroll-loop (nie włączone przez -O3) mogą czasami prowadzić do generowania większej liczby kodów maszynowych. W pewnych okolicznościach (np. Na jednostce centralnej z wyjątkowo małą pamięcią podręczną instrukcji L1) może to spowodować spowolnienie z powodu całego kodu np. Jakiejś wewnętrznej pętli, która nie pasuje już do L1I. Zasadniczo gcc bardzo mocno stara się nie generować tak dużej ilości kodu, ale ponieważ zazwyczaj optymalizuje ogólny przypadek, może się to zdarzyć. Opcje szczególnie na to podatne (jak rozwijanie pętli) zwykle nie są zawarte w -O3 i są odpowiednio oznaczone na stronie podręcznika. W związku z tym ogólnie dobrym pomysłem jest użycie opcji -O3 do generowania szybkiego kodu i polegać tylko na opcji -O2 lub -Os (która próbuje zoptymalizować rozmiar kodu), gdy jest to właściwe (np. Gdy profiler wskazuje brak L1I).

Jeśli chcesz maksymalnie wykorzystać optymalizację, możesz dostosować gcc za pomocą --param kosztów związanych z niektórymi optymalizacjami. Dodatkowo zauważ, że gcc ma teraz możliwość umieszczania atrybutów w funkcjach, które kontrolują ustawienia optymalizacji tylko dla tych funkcji, więc gdy okaże się, że masz problem z -O3 w jednej funkcji (lub chcesz wypróbować specjalne flagi dla tej funkcji), nie musisz kompilować całego pliku ani nawet całego projektu za pomocą O2.

otoh wydaje się, że należy zachować ostrożność podczas używania opcji -Ofast, która stwierdza:

-Ofast włącza wszystkie optymalizacje -O3. Umożliwia także optymalizacje, które nie są prawidłowe dla wszystkich standardowych programów zgodnych.

co prowadzi mnie do wniosku, że -O3 ma być w pełni zgodny ze standardami.

Z mojego nieco szachowego doświadczenia, zastosowanie -O3do całego programu prawie zawsze powoduje spowolnienie (w stosunku do -O2), ponieważ włącza agresywne rozwijanie i wstawianie pętli, które powoduje, że program nie mieści się już w pamięci podręcznej instrukcji. W przypadku większych programów może to być również prawdą w -O2odniesieniu do -Os!

Zamierzonym sposobem użycia -O3jest, po profilowaniu programu, ręczne zastosowanie go do niewielkiej garści plików zawierających krytyczne pętle wewnętrzne, które faktycznie korzystają z tych agresywnych kompromisów między szybkością a szybkością. Nowsze wersje GCC mają tryb optymalizacji sterowany profilem, który może (IIUC) selektywnie stosować -O3optymalizacje do gorących funkcji - skutecznie automatyzując ten proces.

Opcja -O3 włącza droższe optymalizacje, takie jak wstawianie funkcji, oprócz wszystkich optymalizacji niższych poziomów „-O2” i „-O1”. Poziom optymalizacji „-O3” może zwiększyć szybkość wynikowego pliku wykonywalnego, ale może również zwiększyć jego rozmiar. W pewnych okolicznościach, gdy te optymalizacje nie są korzystne, ta opcja może faktycznie spowolnić program.

Tak, O3 jest błędny. Jestem programistą kompilatorów i podczas tworzenia własnego oprogramowania zidentyfikowałem wyraźne i oczywiste błędy gcc spowodowane przez generowanie przez O3 błędnych instrukcji montażu SIMD. Z tego, co widziałem, większość oprogramowania produkcyjnego jest dostarczana z O2, co oznacza, że ​​O3 otrzyma mniej uwagi na testowanie i naprawianie błędów.

Pomyśl o tym w ten sposób: O3 dodaje więcej transformacji na O2, co dodaje więcej transformacji na O1. Statystycznie rzecz biorąc, więcej transformacji oznacza więcej błędów. Dotyczy to każdego kompilatora.

Ostatnio wystąpił problem z korzystaniem z optymalizacji z g++. Problem dotyczył karty PCI, w której rejestry (dla poleceń i danych) były reprezentowane przez adres pamięci. Mój sterownik zamapował adres fizyczny na wskaźnik w aplikacji i podał go wywoływanemu procesowi, który działał z nim w następujący sposób:

unsigned int * pciMemory;
askDriverForMapping( & pciMemory );
...
pciMemory[ 0 ] = someCommandIdx;
pciMemory[ 0 ] = someCommandLength;
for ( int i = 0; i < sizeof( someCommand ); i++ )
    pciMemory[ 0 ] = someCommand[ i ];

Karta nie działała zgodnie z oczekiwaniami. Kiedy zobaczyłem zespół zrozumiałem, że kompilator napisał tylko someCommand[ the last ]dopciMemory , pomijając wszystkie poprzednie zapisy.

Podsumowując: bądź dokładny i uważny dzięki optymalizacji.