Tags Posts tagged with "benchmark"

benchmark

przez -
2 649
Benchmark sprzętu

Geeks3D ogłosiło wydanie GpuTest 0.5.0, który jest wieloplatformowym benchmarkiem testującym naszą kartę graficzną, z użyciem OpenGL. Pod Windows i OS X jest dostępne graficzne narzędzie do obsługi, natomiast pod Linuksem musimy zadowolić się póki co konsolą. Aktualnie dostępne są testy: FurMark, TessMark, GiMark, Triangle i Plot3D.

Udoskonalono wsparcie dla Linuksa, szczególnie dodano lepszą obsługę Mesa 3D oraz Gallium3D. GpuTest potrafi teraz wykorzystywać wszystkie silniki renderowania Gallium3D: LLVMpipe, NVC0, CYPRESS, a także własnościowe sterowniki nVidia i AMD. Niestety, nie testowano kart graficznych Intela.

Dodano dwa nowe testy Gallium3D: Triangle i Plot3D. Ten ostatni jest oparty na algorytmie z artykułu: 3D Surfaces Plots (GLSL). Dostępne są także: Volplosion i Piano.

Porzucono zależność od GLIBC 2.14 na rzecz GLIBC 2.2.5, które jest popularniejsze w starszych dystrybucjach. Dodano nową komendę: /debug_log_frame_data.

Zaktualizowaliśmy również nasz artykuł: GpuTest – FurMark i TessMark pod Linuksem.

przez -
4 424

Open Source Technology Center to centrum badawcze należące do firmy Intel. W ostatnim czasie udostępnili oni 13 linuksowych benchmarków, które były używane wewnętrznie do testów dystrybucji i jądra Linux. Zostały one zbudowane w oparciu o Phoronix Test Suite i OpenBenchmarking.org, dzięki czemu można je znaleźć w już w zaktualizowanym Phoronix Test Suite 4.2.

Oto pełna lista:

  • gpu-residency – sprawdza aktywność wbudowanej karty graficznej, kwestii RC6 i RC6P przez 60 sekund
  • noise-level – test sprawdza aktywność w tle
  • powertop-wakeups – testuje wybudzenia ze spoczynku na każdą sekundę w danym przedziale czasu
  • systemd-boot-kernel – test analizuje czas startu jądra
  • systemd-boot-total – test analizuje łączny czas uruchamiania
  • systemd-boot-userspace – test analizuje łączny czas uruchamiania przestrzeni użytkownika
  • system-decompress-bzip2 – test sprawdza czas dekompresji paczki jądra Linux używając BZIP2
  • system-decompress-gzip – test sprawdza czas dekompresji paczki jądra Linux używając gzip
  • system-decompress-tiff – test sprawdza czas dekompresji obrazka z TIFF do RGBA
  • system-decompress-xz – test sprawdza czas dekompresji paczki jądra Linux używając xz
  • system-decompress-zlib – test sprawdza czas dekompresji paczki jądra Linux używając zlib
  • system-libjpeg – test sprawdza czas kodowania pliku jpeg przy użyciu systemowej biblioteki libjpeg
  • system-libxml2 – test sprawdza czas przeanalizowania losowego pliku XML z libxml2 poprzez xmllint, używając API do strumieniowania

Sprzęt, Dysk twardy

Wiele osób, zaraz po instalacji systemu operacyjnego chciałaby zobaczyć podstawowe informacje o parametrach komputera i zainstalowanych w nim urządzeń. Najłatwiejszym sposobem, aby to zrobić pod Linuksem jest skorzystanie z konsoli i wydanie odpowiednich poleceń. Jednakże, co w przypadku, kiedy potrzebujemy szczegółowy raport w kilka chwil i najlepiej, aby został on jeszcze wydrukowany? Z pomocą przychodzi nam HardInfo.

HardInfo jest darmowym oprogramowaniem, który dostarcza szczegółowe informacje o wszystkich zainstalowanych w komputerze komponentach. Standardowo znajduje się w praktycznie każdej dystrybucji Linuksa i nie trzeba dodawać żadnych dodatkowych repozytoriów, czy pobierać zewnętrznych paczek.

Computer

W tej zakładce możemy zobaczyć informacje o całym komputerze, systemie operacyjnym, modułach jądra, uruchomieniach systemu, językach, systemach plików, wyświetlaczu, zmiennych środowiskowych i użytkownikach.

HardInfo - Computer - Summary HardInfo - Computer - Languages

Devices

Tutaj znajdziemy wszelakie informacje o sprzęcie: procesor, pamięć, urządzenia PCI, urządzenia USB, drukarki, baterie, czujniki, urządzenia wejściowe, nośniki danych, płycie głównej i zasobach.

HardInfo - Devices - Processor

Network

Ta zakładka dostarcza informacji o sieci. Mamy zatem: interfejsy, połączenia IP, tabele rutingu, tabele ARP, serwery DNS, statystyki i współdzielone katalogi.

Benchmarks

Ostatnia zakładka to proste testy diagnostyczne. Znajdziemy w niej CPU Blowfish, CPU CryptoHash, CPU Fibonacci, CPU N-Queens, FPU FFT, FPU Raytracing.

HardInfo - Benchmark - testowanie wydajności

Generowanie raportów

Dużą zaletą aplikacji jest możliwość wygenerowania raportu o całym posiadanym sprzęcie. Trwa to dosłownie chwilę, a wynik jest udostępniany w postaci pliku HTML – hardinfo_report.html. Sami wybieramy sobie, jakie części komputera mają znaleźć się w naszym raporcie. Jeżeli wcześniej nie robiliśmy testów wydajności, to generator zrobi to za nas automatycznie.

HardInfo - Generowanie raportu

przez -
35 2004
Benchmark oprogramowania

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:
Wyznacznik macierzy C

Wykres dla C++:
Wyznacznik macierzy 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:
Wyznaczanie SHA-1 – C

Wykres dla C++:
Wyznaczanie SHA-1 – 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.

Benchmark Adobe

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

Lame mp3 - konwersja WAV na mp3

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:

Lame MP3 - konwersja WAV na MP3

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ę:

Lame MP3 - konwersja WAV na MP3 - Audacity

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
POV-Ray

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:

POV-Ray - OK POV-Ray - Błąd

Po lewej stronie mamy poprawny render, a po prawej agresywną niebezpieczną optymalizacją
Różnica tych 2 obrazów wykonana w GIMPie
POV-Ray: 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):

OpenCC - Różnice

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.

Polecane

Jesień Linuksowa

1 717
Polska Grupa Użytkowników Linuksa ma zaszczyt zaprosić na konferencję Jesień Linuksowa 2017, która odbędzie się w dniach 22 – 24 września 2017 roku. Jako...