Benchmark kompilatorów i konsekwencje optymalizacji

Obecnie mamy wiele dostępnych kompilatorów. Obecnie GCC jest najpopularniejszym kompilatorem (zbiorem kompilatorów) pod Linuksami, *BSD i innych OpenSource’owych systemów, a także ma swój port na Windowsa (w pakiecie MinGW). Ale są także inne. Czym one się różnią między sobą i jaki mają wpływ na wydajność aplikacji? Jak duży wpływ na wydajność programu ma jego optymalizacja przez kompilator? Czy ma to w ogóle sens, czy te różnice są zauważalne. O tym w dowiecie się z tego artykułu.

Do testów postanowiłem wybrać następujące kompilatory:

• GCC w wersji 4.6.3 (obecna na Ubuntu)
• GCC w wersji 4.7.1 (ręcznie skompilowany)
• Clang 3.0 (z repozytoriów)
• TinyCC (mały kompilator C, dostępny w repo)
• Open64 (pobrany z oficjalnej strony w formie skompilowanej)

Który z tych kompilatorów okaże się najlepszy? Małego benchmark został wykonany na mojej maszynie Acer Aspire 5552:

• AMD Athlon X2 P320 2100MHz
• 6 GiB RAM DDR3
• system Linux Mint 13 64-bit (Linux 3.2.0-29-generic x86_64)
• lekkie środowisko razor-qt z menedżerem OpenBox

Kompilatory testował będę z różnymi opcjami kompilacji przy pomocy kilku algorytmów i OpenSource’owych praktycznych aplikacji:

• wyznacznik macierzy 10×10 (C i C++)
• sha-1 – liczenie sumy kontrolnej dużych plików (C i C++)
• Adobe C++ Benchmark
• lame mp3 – kodowanie plików mp3 (C)
• POV-Ray – renderer grafiki 3D

Niepewność pomiarów

Jako że pomiary czasów wykonywane są w wielozadaniowym systemie, na czas jest zależny od tego, co system w danym czasie ma do roboty. Zmieniłem więc ociężałe KDE na lekkiego razor-qt z menedżerem okiem OpenBox. W czasie wykonywania testów system był odłączony od internetu i stał kompletnie nieużywany, w tym czasie czytałem pewną książkę, albo grałem na starym piecu.

Testy były w dużej mierze zautomatyzowane, dzięki czemu mogłem je uruchomić i zostawić na godzinę. Nie ukrywam, że wiele razy musiałem poprawiać skrypty i powtarzać testy. Jeśli chodzi o niedokładność, to była niewielka: ok 2%. Testy były wykonywane kilka razy, przy zbyt dużym odchyleniu powtarzałem serię testów uzyskując bardzo zbliżone wyniki.

Kompilatory

GCC każdy zna. Podstawowy kompilator w Linuksie i wielu innych systemach. Stabilny, w miarę szybki, funkcjonalny.

„CLang to nieco „nowość”:, wprowadzany jako standardowy w systemach BSD. Jest rozwijany (a raczej finansowany) przez Apple, którego korci jego licencja: BSD. Pisany jest pod wzór GCC i jest obsługiwany tak samo, jednak potrafi kompilować podobno do 4 razy szybciej, a kody wynikowe są do 20% szybsze. Clang jest częścią LLVM, jako standardowy kompilator C/C++.

Open64 to otwarty kompilator C/C++ i Fortrana. Sam o nim nie wiedziałem zbyt wiele do niedawna. Również ma taką samą składnię wywołań jak GCC, dzięki czemu łatwo było napisać testy.

TinyCC to raczej tylko ciekawostka. Malutki kompilatorek nieposiadający żadnych specjalnych cech.

Profile kompilacji

Testy na prostszych przykładach wykonywałem na następujących profilach:

• I. „-O0” – brak optymalizacji, flaga dodana, ponieważ Open64 domyślnie ma ustawioną chyba -O2.
• II. „-O2” – optymalizacja drugiego poziomu
• III. „-O3” – optymalizacja trzeciego poziomu
• IV. „-O3 -ffast-math” -trzeci poziom z przyspieszoną arytmetyką
• V. „-O3 -march=k8 -msse2” – z dopasowanem do procesorów k8 + SSE2*
• VI. „-O3 -ffast-math -march=k8 -msse2” – punkty 5+4

*W kodach nie było „wymuszenia” SSE2, jednak drogą optymalizacji kompilator może znaleźć pętle z operacjami, które może zwektoryzować i wykonać poprzez SSE.

Wybrany został procesor k8, ponieważ jest najbliższy mojej architektury, a native nie działa na wszystkich tych kompilatorach (przykładowo wg.Open64 nie posiadam SSE2). Czasy na wykresach podane w sekundach, chyba że napisano inaczej.

Wyznacznik macierzy 10×10

Test na szybkość przy wywołaniach rekurencyjnych, alokowaniu i dealokowaniu danych oraz obliczeniach zmiennoprzecinkowych. Dysponowałem dwoma algorytmami: czysty C i rozwiązanie w C++ z klasami. Algorytm jest ten sam: rekurencyjne rozwinięcie Laplace’a. Program obliczał wyznaczniki 10 macierzy wczytanych z pliku.

Wykres dla C:

Wykres dla C++:

Opcje kompilacji nie miały większego znaczenia (oczywiście poza -O2, który zawsze przyspiesza). W C najszybszy kod wynikowy wyprodukował Clang i Open64, choć i tak przewaga jest niewielka w stosunku do GCC. W C++ zaś najszybszy kod wyprodukował GCC 4.6.1. Zauważyć można też przyspieszenie przy użyciu flagi -ffast-math.

Wyznaczanie SHA-1

Niewiele dający, ale jednak. Plikiem którego suma SHA-1 była wyznaczana był videotutorial do Blendera. Ważył on 206 MiB. Jako że następuje tu odczytywanie z dysku, wyniki mogły zakłócić dodatkowe operacje na dysku.

Wykres dla C:

Wykres dla C++:

Jeśli chodzi o C, opcje kompilacji również miały tu niewiele do powiedzenia, choć przy Open64 można zauważyć że kod „-O2” jest szybszy niż „-O3”. Przypadek? Może, aczkolwiek wynik taki wyszedł w przypadku wszystkich 3 przeprowadzonych serii. W algorytmie C++ jest znacznie większe zróżnicowanie. Open64 również pokazuje, że kod z „-O2” jest szybszy od trzeciego poziomu, ale dostosowanie architektury poprawia nieco wynik.

Nowy GCC natomiast jakby kompletnie nie wiedział co z tą architekturą zrobić, wynikowy kod jest wolniejszy. Co prawda w tym teście nie występują liczby zmiennoprzecinkowe, więc „-ffast-math” po prostu nie ma wpływu na wynik, ale pokazuje, że wyniki są w miarę stabilne (pary III i IV, oraz V i VI mają względnie takie same czasy).

Benchmark Adobe’a

Szukając algorytmów do testów natknąłem się na paczkę testów od Adobe’a, można go znaleźć na tej stronie: stlab.adobe.com/performance.

Nie zmieniałem opcji kompilacji, zmierzyłem czas wykonywania całej serii testów dla wszystkich 4 testowanych kompilatorów C++. Testy były baaaardzo długie, więc byłem zmuszone je trochę skrócić (zmniejszyć ilość iteracji). To benchmark z prawdziwego zdarzenia testujący konkretne optymalizacje. Ten test był wykonany tylko 2 razy, co i tak trwało 2*40 minut (wyniki były bardzo zbliżone, niemal identyczne). Ukazuje mocne i słabe strony kompilatorów.

Poszczególne czasy nie są istotne (były dość rozbieżne czasy poszczególnych testów, więc nie wyglądałoby to zbyt czytelnie na jednym wykresie), wszystkie są pokazane względem czasów GCC 4.6.3. Według tego testu GCC nie jest aż taki szybki. Testy wykonane były z tylko jedną flagą: -O3. Najszybszy jest to Open64! Najdłuższym testem był ./loop_unroll. Jednak benchmark benchmarkiem, jak jest w praktyce?

Lame MP3 – konwersja WAV na MP3

Do testów posłużył oryginalny WAV ze zrippowanej oryginalnej płyty (ponad 5-minutowy Thrash Metalowy utwór). Tiny C Compiler niestety nie podołał temu zadaniu. Wykonałem 2 serie testów mierząc czas wszystkich etapów, gdzie kompilator ma coś do gadania. Kompilacja odbyła się przy domyślnych w tym projekcie opcjach kompilacji:

-O3 -fomit-frame-pointer -ffast-math -Wall -pipe

Czasy konwersji nie były zbyt zróżnicowane, jednak ciekawe są przypadki konfiguracji i budowania. Skrypt ./configure najdłużej wykonywał się dla Open64 i to aż trzykrotnie! Najszybszym kompilatorem okazał się Clang, a najwolniejszym Open64. Tu również GCC 4.7.1 przegrywa ze swoim poprzednikiem. Stwierdziłem że to za mało. Pobawiłem się nieco flagami i uzyskałem lepszy czas:

Ale niestety nic za darmo: suma kontrolna pliku test.mp3 była inna (osobiście nie słyszę różnicy). Dowodzi to temu, że przesadzenie z agresywnymi niebezpiecznymi optymalizacjami może wpłynąć nie tylko na szybkość, ale i sam wynik zbudowanego programu! Flagi użyte przy kompilacji oznaczonej opt:

O3 -pipe -march=k8 -msse -msse2 -funsafe-math-optimizations -funroll-loops -funsafe-loop-optimizations -m3dnow -mfpmath=sse

Oczywiście najlepszy efekt osiągnął GCC w wersji 4.6.3. Pozostałe kompilatory nie były testowane, ponieważ nie rozpoznawały części tych flag (nie znalazłem odpowiedników), a bez nich różnica była nieznacząca. Przy użyciu jakże profesjonalnego oprogramowania zwany Audacity postanowiłem zbadać różnicę. Załadowałem plik skonwertowany normalnym lame’em i tym zbyt zoptymalizowanym, jeden z nich „odwróciłem w pionie” i zmiksowałem obie ścieżki. Jak wychodzi z prostego równania: x+x*(-1), musi wyjść 0, a tu proszę:

Przy przybliżeniu okazuje się, że cała ścieżka jest miejscami pofałdowana, czego nie osobiście nie słyszę ani na moich słuchawkach na USB, ani na głośnikach (może na sprzęcie za 10 tys. zł byłoby słychać jakąś różnicę). Mimo wszystko technicznie różnica jest. O ile pierwszy skok można wytłumaczyć nagłą zmianą nastroju utworu, to nie rozumiem czemu są takie nagłe zmiany w środku utworu, gdzie nie działo się nic specjalnego.

POV-Ray

To samodzielny renderer grafiki 3D znany ze swojej prostoty i względnie sporych możliwościach. Ten test nie objął nowego GCC – były problemy z automatyzacją – nie chciał się zbudować z nieznanych powodów, gdy ustawiałem własny prefiks (podobnie Open64, ale jego zbadałem ręcznie). Flagi kompilacji wykorzystałem standardowe:

-O3 -march=k8 -mtune=k8 -msse -msse2 -mfpmath=sse -malign-double -minline-all-stringops

Oraz zrobiłem test dla GCC z następującymi flagami:

-O3 -pipe -march=k8 -msse -msse2 -funsafe-math-optimizations -funroll-loops -funsafe-loop-optimizations -malign-double -m3dnow -mfpmath=sse

Wyniki testu

Znów Clang okazał się demonem prędkości kompilacji, a GCC wyprodukował szyszy kod. Niebezpieczne optymalizacje skróciły czas rysowania sceny benchmark, jednak jakim kosztem? Oto porównanie:

Po lewej stronie mamy poprawny render, a po prawej agresywną niebezpieczną optymalizacjąRóżnica tych 2 obrazów wykonana w GIMPie

W tym przypadku różnice widać nawet gołym okiem (zmieniając z jednego obrazka na drugi). Różnice też pokazały się na jednej ze scen radiosity, jednak dotyczą one jedynie kilku krawędzi, który były inaczej wygładzone. Wynik sceny benchmark również był inny dla kompilatora Open64, różnica względem oryginału była podobna do różnicy pokazanej wyżej, a oto różnice w serii radiosity (po lewej normalny, pośrodku wynik OpenCC, po prawej różnica):

Podsumowanie

Testy wyraźnie pokazują, że powiedzienie szybki język nie jest poprawne: wszystko zależy od implementacji języka (kompilatora) oraz opcji kompilacji. Optymalizacje kompilatora skracają czas wykonania kodu wynikowego często nawet o połowę! Czasem włączenie flag pod architekturę k8 spowodowało nieznaczne zwolnienie..

Mimo że na specjalnym benchmarku królował wręcz Open64, w praktyce nie szło mu tak dobrze, w testowanych programach nie było tak szablonowych pętel, które kompilatory mogłyby bardzo łatwo rozpoznać. Rozczarowujący jest wynik GCC 4.7.1, który osiąga gorsze rezultaty od swojego poprzednika, jednak lepiej wspiera nowsze standardy takie jak C++11.

W każdym razie test pokazał że kompilator kompilatorowi nierówny i nie da się jednoznacznie wyłonić najlepszego. Tym samym może się okazać, że kompilatory tworzą zupełnie różne programy tworzące różne wyniki.