Kompilowanie GNU / Linux z optymalizacją -O3

Mówi się, że kompilacja narzędzi GNU i jądra Linuksa z -O3opcją optymalizacji gcc spowoduje dziwne i funky błędy. Czy to prawda? Czy ktoś tego próbował, czy to tylko mistyfikacja?

Jest używany w Gentoo i nie zauważyłem niczego niezwykłego.

-O3 ma kilka wad:

1. Przede wszystkim często generuje wolniejszy kod niż -O2lub -Os. Czasami produkuje dłuższy kod z powodu rozwijania pętli, co może być w rzeczywistości wolniejsze z powodu gorszej wydajności pamięci podręcznej kodu.
2. Jak powiedziano, czasami produkuje zły kod. Może to być spowodowane błędem w optymalizacji lub błędem w kodzie (np. Ignorowanie ścisłego aliasingu). Ponieważ kod jądra czasami jest, a czasem musi być „inteligentny”, powiedziałbym, że możliwe jest, że jakiś programista jądra popełnił błąd. Doświadczyłem różnych dziwnych problemów, takich jak zawieszanie się narzędzi przestrzeni użytkownika, kiedy skompilowałem jądro z gcc 4.5, które w tym momencie było stabilne. Nadal używam gcc 4.4 dla jądra i kilku wybranych narzędzi przestrzeni użytkownika z powodu różnych błędów. To samo może dotyczyć -O3.
3. Nie sądzę, że oferuje wiele korzyści dla jądra Linuksa. Jądro nie wykonuje ciężkich obliczeń, aw niektórych miejscach jest zoptymalizowane pod kątem montażu. -O3Flaga nie zmieni kosztu przełączania kontekstu ani szybkości I / O. Nie sądzę, aby coś takiego jak przyspieszenie ogólnej wydajności o <0,1% było tego warte.

Zauważ, że duże fragmenty łańcucha narzędzi (w szczególności glibc) nie kompilują się, jeśli zmienisz poziomy optymalizacji. System kompilacji jest skonfigurowany tak, aby ignorować preferencje -O dla tych sekcji w większości rozsądnych dystrybucji.

Krótko mówiąc, niektóre podstawowe funkcje biblioteki i systemu operacyjnego zależą od tego, czy kod faktycznie robi to, co mówi, a nie co w wielu przypadkach byłoby szybsze. W szczególności -fgcse-after-reload (włączony przez -O3) może powodować dziwne problemy.

W ciągu ostatnich 10 lat korzystałem z wielu systemów Gentoo z ponad 1000 pakietów na -O3 -march=nativecałym świecie i nie spotkałem się z żadnym z tych mitycznych problemów ze stabilnością, które -O3powinny mieć. Testy porównawcze aplikacji intensywnie wykorzystujących procesor (takich jak aplikacje matematyczne / naukowe) konsekwentnie pokazują -O3szybsze tworzenie kodu, w końcu nie miałoby sensu, gdyby tak nie było. W większości aplikacji komputerowych i CFLAGStak nie ma to większego znaczenia, ponieważ są one związane z IO, ale ma to duże znaczenie dla rzeczy po stronie serwera, które są związane z procesorem.

-O3 stosuje pewne agresywne optymalizacje, które są bezpieczne tylko wtedy, gdy pewne założenia dotyczące użycia rejestru, sposobu interakcji ramek stosu i ponownego wprowadzenia funkcji są prawdziwe, a te założenia nie są gwarantowane w niektórych kodach, takich jak jądro, szczególnie gdy zestaw wbudowany jest używane (tak jak w niektórych bardzo niskim poziomie części jądra i jego modułów sterownika).

Podczas gdy można uniknąć używania opcji -O3 i innych pokręteł optymalizacji w większości aplikacji (i może to spowodować poprawę prędkości), wahałbym się użyć takich poprawek samego jądra lub łańcucha narzędzi wymaganych do jego zbudowania (kompilator, binutils, itp.).

Pomyśl o tym: czy wzrost wydajności podsystemów RAID i ext3 o 5% jest warty awarii systemu lub potencjalnej utraty danych i / lub uszkodzenia?

Ulepsz wszystkie pokrętła, które chcesz dla tego odtwarzanego portu Quake lub kodeków audio / wideo używanych do zgrywania kolekcji DVD do plików divx. Prawdopodobnie zauważysz poprawę. Po prostu nie zadzieraj z jądrem, chyba że masz czas do stracenia i dane, które możesz znieść, aby je stracić.