Pochodzące z łat jądra Linuksa z ostatnich tygodni sugerujących eksperymentalną opcję-O3 dla wszystkich architektur procesora i dość szybko odrzucającego ją Linusa Torvalda, oto kilka nowych testów porównawczych dotyczących Wydajność jądra Linuksa, gdy obraz jądra jest przebudowywany z poziomem optymalizacji-O3, a nie-O2.
Podobnie jak podczas poprzednich prób, gdy przywołano optymalizację-O3 jądra Linuksa, Linus Torvalds wyraził zaniepokojenie faktem, że kompilator GCC przynajmniej historycznie generował gorszy kod niż-O2, a czasami nawet generował niepoprawny/błędny kod, zwłaszcza gdy miał do czynienia z zachowaniem jądra niskiego poziomu. Szczególnie w przypadku ogromnej bestii, jaką jest jądro Linuksa, debugowanie jądra może być trudne, gdy jest to wywołane przez kompilator generujący nieco zły kod i może nie być od razu zauważalne przez użytkownika/programistę.
W przypadku Nazwa bezpieczeństwa i wspomnienia z czasów, gdy kompilator GCC nie zawsze był niezawodny w swoich optymalizacjach, Linus Torvalds jest oczywiście ostrożny w kwestii agresywnych optymalizacji kompilatorów dla jądra Linuksa. Dodatkowo, poprawki z zeszłego tygodnia nie dostarczyły żadnego ilościowego uzasadnienia dla proponowanego eksperymentalnego „CC_OPTIMIZE_FOR_PERFORMANCE_O3” w poszerzeniu tego poza istniejącą dostrajalną architekturę ARC.
Poziom optymalizacji-O3 można również łatwo ustawić za pomocą Zmienna środowiskowa”KCFLAGS”do ustawiania CFLAGS jądra. Dzięki temu i ponieważ od lat nie zajmowałem się porównaniami poziomów optymalizacji kompilatora dla samego jądra Linuksa, przeprowadziłem kilka nowych testów porównawczych kompilacji jądra w wersji-O3.
W tym artykule przeprowadziłem testy porównawcze. tego samego stanu Git Linux 5.19 podczas budowania jądra z ustawioną wartością KCFLAGS=-O2 (domyślnie), a następnie ponownie odbudowując ten sam stan jądra i ten sam Kconfig z ustawioną wartością KCFLAGS=-O3 dla bardziej agresywnego poziomu optymalizacji kompilatora. CFLAGS/CXXFLAGS nie zostały zmienione w testach porównawczych open source — pliki binarne w przestrzeni użytkownika były takie same jak 1:1, a podczas procesu testowania zmieniano tylko jądro Linuksa.
Wszystkie ten test został przeprowadzony na średniej klasy komputerze stacjonarnym z procesorem Intel Core i5 12600K „Alder Lake”. Przeprowadzono szeroki zakres syntetycznych i rzeczywistych testów porównawczych, aby przyjrzeć się wpływowi kompilacji jądra-O3 na-O2. Zobaczmy więc, co oznacza jądro-O3 w 2022 r. podczas korzystania z Ubuntu 22.04 LTS z nowoczesną (ale nie najnowszą) wersją kompilatora GCC 11.
W szeregu testów I/O jądro-O3 * czasami* dawał nieco lepszą wydajność, gdy nie był związany z podstawową prędkością przechowywania. Jednak te zyski były zwykle bardzo cienkie i można je było przypisać szumowi poza tym regularnie słabym ołowiem w budowie jądra-O3. Ale żaden normalny użytkownik nie zauważyłby istotnej różnicy dla I/O z jądrem zoptymalizowanym pod kątem-O3.
Podczas uruchamiania różnych gier OpenGL i Vulkan oraz innych testów graficznych, nie było żadnej mierzalnej różnicy w stosunku do-O3 kompilacja jądra. Jeśli-O3 zoptymalizowanie komponentów sterownika Mesa w przestrzeni użytkownika i samej gry jest prawdopodobnie bardziej zauważalnym skutkiem niż optymalizacja jądra-O3.
Lub z oprogramowaniem do wizualizacji stacji roboczej ParaView, nie ma różnicy z-Kompilacja jądra O3.
Jeśli chodzi o wydajność sieci z testowaniem przy użyciu programu Microsoft’s Ethr do analizy, kompilacja jądra-O3 prowadziła do pewnych niewielkich, stałych ulepszeń w tych testach porównawczych. Jednak te ulepszenia sieci prawdopodobnie pozostaną niezauważone przez żadnego użytkownika końcowego. Serwery o wysokiej wydajności wykonujące dużą aktywność sieciową mogą odnieść korzyści, ale administratorzy systemów będą mniej skłonni do rozważenia kompilacji jądra-O3 ze względu na większe ryzyko wad jądra w wyniku nieprawidłowej optymalizacji.
Testy porównawcze Sockperf jeszcze bardziej wzmocniły pewne korzyści płynące z jądra zoptymalizowanego pod kątem-O3.
Kompozycja jądra-O3 wykazała ledwie poprawę w przypadku testu w jądrze WireGuard.
Niektóre jądro syntetyczne-z myślą o testach porównawczych, takich jak perf-bench, pojawiły się pewne niewielkie korzyści podczas pracy ze zoptymalizowaną wersją jądra-O3.
Niektóre testy porównawcze jądra Stress-NG również wykazały poprawę z jądrem-O3, ale nie przekładać koniecznie na zyski w świecie rzeczywistym…
Spośród wszystkich przeprowadzonych testów porównawczych, test przełączania kontekstu Stress-NG odnotował największy zysk ze zoptymalizowanej budowy jądra-O3.
Wielka wygrana w przełączaniu kontekstu Stress-NG nie przełożyła się jednak koniecznie na przełączanie w szerokim kontekście ben pasuje jak w przypadku ctx-clock, na przykład nie zaobserwowano zmian w wydajności.
Tymczasem, ponieważ w dużej mierze przestrzeń użytkownika zawierała aplikacje ze świata rzeczywistego, nie było zbyt wiele do opisania na temat budowy jądra-O3. Znalezienie jakichkolwiek korzyści z kompilacji jądra `-O3 w rzeczywistym świecie, obciążenia produkcyjne były trudne, nawet przy zróżnicowanym zakresie testowanych obciążeń.
Biblioteka komunikacyjna PJSIP obsługująca różne protokoły wykazała pewne korzyści, ale znowu ten konkretny test porównawczy jest raczej syntetyczny.
Serwer bazy danych PostgreSQL, gdy jest przeciążony zapytaniami, znalazł pewne korzyści w zoptymalizowanym obrazie jądra-O3.
Dla niektórych testów porównawczych serwerów baz danych RocksDB pojawiło się kilka drobnych ulepszeń związanych z budowaniem jądra-O3.
Memcached był jednym z niewielu innych obszarów o znaczeniu rzeczywistym, korzystających z kompilacji jądra-O3.
Nie wszystkie systemy baz danych korzystały z wersji jądra-O3…
Serwer sieciowy Apache działający na jądrze-O3 odnotował pewne ulepszenia wydajności w podstawowej wydajności obsługi sieci HTTP dla statycznej zawartości HTML.
W sumie przeprowadziłem 230 różnych testów na kompilacjach jądra-O2 i-O3. Ponownie, ta sama ogólna wersja Kconfig i jądra używana do testowania, jedyną zmianą było przełączenie-O2 na-O3 dla KCFLAGS. Podczas tych testów wszystkie flagi testowe dla oprogramowania przestrzeni użytkownika były takie same. Ci, którzy chcą w pełni sprawdzić wszystkie 230 wskaźników, mogą to zrobić na tej stronie wyników OpenBenchmarking.org.
Biorąc średnią geometryczną wszystkich 230 wyników testów porównawczych, kompilacja jądra-O3 wyszła na prowadzenie tylko o 1,3%… Ogólnie rzecz biorąc, ledwie drobny skok. Lub jeśli po prostu przyjrzysz się obciążeniom z różnicą powyżej 2%:
Najbardziej znaczącą różnicą był test porównawczy przełączania kontekstu Stress-NG, ale wydajność przełączania kontekstu mierzona zegarem ctx na przykład został niezmieniony. Oprócz tej wartości odstającej, we wszystkich innych testach jądro-O3 było o 11% szybsze lub mniej, ale najczęściej o 5% lub mniej…. Po zignorowaniu bardzo syntetycznych testów porównawczych, zyski na jądrze-O3 stwierdzono w niektórych systemy baz danych, takie jak PostgreSQL i RocksDB/LevelDB. Zauważono również pewne korzyści z serwerem WWW Apache HTTPD. W testach sieciowych, takich jak Ethr, pojawiły się również pewne ulepszenia, ale przynajmniej w przypadku przeprowadzonych testów są syntetyczne testy porównawcze.
W przypadku, gdy zoptymalizowana kompilacja jądra-O3 miała pewną zaletę, znajdowała się w ramach obciążeń serwera. Jednak prawdopodobnie jest to najmniej tam, gdzie administratorzy serwerów byliby zadowoleni z optymalizacji-O3, biorąc pod uwagę możliwość-przynajmniej historycznie-optymalizacji generujących niepoprawny/błędny kod, zwłaszcza gdy w kontekście jądra może być subtelne, trudne do debugowania uruchomienie problemy z czasem.
Kiedy przyszło do kompilacji jądra-O3 dla innych obciążeń, takich jak gry/grafika, wydajność przeglądania stron internetowych i różne obciążenia twórców, nie było wymiernych korzyści z jądra-O3.
