Moje zdjęcie

imię: Piotr Sowiński
pseudo: Sadi
wiek: 25
zainteresowania: programowanie, tworzenie stron, linux, elektronika, książki


Creative Commons LicenseJeżeli nie zaznaczono inaczej, wszystkie materiały na tej stronie są objęte licencją Creative Commons by-nc 3.0
Skiny
grey-tea green (standardowy)
light sky blue
carrot orange
Polecam

Bykom STOP! browsehappy.pl - masz kIEpską przeglądarkę? Spam Poison - zatrujmy życie spammerom! Debian GNU/Linux Przeglądarka Opera
Opłacalność kompilacji jądra sadi | 00:19 | 02.03.2010
Korzystając z wolnego czasu podczas sesji poprawkowej, oraz z niedawnego wyjścia Phoronix Test Suite w wersji 2.4 zabrałem się za testowanie. Początkowo założenie było takie, żeby sprawdzić ile tak naprawdę dają różne ciekawe opcje ustawiane przed kompilacją jądra (make menuconfig). W kręgu moich zainteresowań były:

1) Processor type and features > Processor family
2) General setup > Optimize for size
3) Processor type and features > Preemption Model
4) Processor type and features > Timer frequency

Dwie pierwsze opcje mają bezpośrednie przełożenie na flagi optymalizujące kompilatora, dlatego w ich przypadku liczyłem na pewną poprawę. Opcja 2 nie wydaje się zbyt obiecująca dopóki nie wyczytamy, że włączona daje kompilatorowi flagę -Os, a wyłączona flagę -O2 (niezorientowanych odsyłam do man gcc). Odpowiednie zmiany w dwóch kolejnych opcjach powodują, że Linux powinien się zachowywać bardziej jak system czasu rzeczywistego (ang. RTOS - odsyłam do Wikipedii/Google). Tu przyznaję, że sam do końca nie wiedziałem czego się spodziewać, choć wiedziałem, że niekoniecznie musi to być poprawa.

Inne (pozornie) ciekawe opcje, których nie sprawdzałem:
5) General setup > Kernel compression mode (Gzip)
6) Enable the block layer > IO Schedulers > Default I/O scheduler (CFQ)

Opcje te nie są ciekawe, ponieważ Debian (i prawdopodobnie większość innych dystrybucji też) stosuje już najbardziej optymalną konfigurację. Opcja 5 nie ma przełożenia na szybkość działania jądra, ale zależy od niej jego rozmiar i to jak szybko zostanie ono rozpakowane przy starcie systemu. Na obecnych komputerach rozmiar jądra naprawdę nie jest czymś specjalnie istotnym (mimo, że wielu ludzi zdaje się sądzić, że jest inaczej). Co innego algorytm jakim zostało ono spakowane. Zarówno Bzip2, jak i LZMA rozpakowują pliki znacznie dłużej niż Gzip, a tym samym ich zastosowanie wydłuża minimalnie start Linuksa. Warto zaznaczyć, że w jądrze 2.6.33 pojawiła się tam do wyboru nowa opcja - LZO. Jest ona o tyle obiecująca, że choć jądro zwiększa rozmiar o ok. 10% w stosunku do Gzip, to rozpakowuje się znacznie szybciej. Co do opcji nr 6, to chyba każda dystrybucja wybiera obecnie CFQ, jako swój standardowy I/O scheduler. Co tu dużo mówić - jest najnowszy, najbardziej zaawansowany i najbardziej uniwersalny. W rezultacie w 95% przypadków jest najlepszym wyborem.

Przejdźmy dalej. Od razu powiem szczerze, że spora część testów od ludzi z Phoronix naprawdę niewiele mi mówi i nie wiem do końca co każdy z nich właściwie sprawdza. Dlatego postanowiłem im zaufać i wybrałem zestaw testów pod nazwą "linux-system", który opisali tak: "A collection of tests designed to test the overall performance of a desktop computer". Zauważyłem, że nie ma tam jednak żadnego testu sprawdzającego wydajność karty graficznej. Dlatego zrobiłem trzy kolejne testy: Lightsmark, Unigine Sanctuary i Urban Terror. Pierwsze dwa dlatego, że są bardzo zaawansowane technicznie, w dodatku Unigine to prawdziwy silnik 3D, który będzie wykorzystany w przyszłych grach. Natomiast Urban Terror to benchmark zrobiony na podstawie obecnej gry. Aby zrobić te wszystkie testy musiałem wydać komendę:
$ phoronix-test-suite benchmark linux-system lightsmark unigine-sanctuary urbanterror

Phoronix Test Suite sam ściąga odpowiednie pliki (uwaga - sporo one zajmują...). Niestety nie obyło się u mnie bez jednej niespodzianki. PTS nie mógł ściągnąć plików potrzebnych do testu graphics-magick. Z problemem poradziłem sobie dodając odpowiednie adresy do pliku /usr/share/phoronix-test-suite/pts/test-resources/graphics-magick/downloads.xml. Gdy już wszystko się ściągnęło i przygotowało, zaczął się ciąg testów, który trwał na moim komputerze ok. 4 godzin. Dlatego testy kolejnych jąder zdecydowałem się robić nocami. Ostatecznie przetestowałem ich 6:
  • 2.6.32.3-sadi
  • 2.6.32.8-sadi
  • 2.6.32.8-test1
  • 2.6.32.8-test2
  • 2.6.32.8-test3
  • 2.6.32-2-amd64
Teraz należy się kilka słów wyjaśnień. Jądro z oznaczeniem "test1" ma oryginalną konfigurację Debiana. Wersja "test2" jest taka sama, jak "test1", ale typ procesora (opcja nr 1) została zmieniona z "Generic-x86-64", na teoretycznie lepszy dla mojego procesora "Core 2/newer Xeon". Jądro z oznaczeniem "test3" jest takie jak poprzednie, ale dodatkowo wyłączyłem opcję nr 2. Obie wersje oznaczone jako "sadi" mają dodatkowo ustawione "Preemptible Kernel (Low-Latency Desktop)" w opcji nr 3 i "Timer frequency (1000 HZ)" w opcji nr 4. Natomiast jądro 2.6.32-2-amd64, jako jedyne z listy nie zostało skompilowane przeze mnie - pochodzi z repozytorium Debiana i pełni funkcję kontrolną.

Oto pełne wyniki przeprowadzonych przeze mnie testów.

Wnioski
Większość testów zwróciła wyniki ukazujące różnice na poziomie 1% lub mniejsze. Trudno wyłonić jednoznacznego zwycięzcę. W każdym razie widać, że raczej nie opłaca się iść bardziej w stronę systemu czasu rzeczywistego. Opcja "Optimize for size" zdaje się mieć większe znaczenie, niż wybrany typ procesora. Ostatecznie jednak odkładam zwrócenie uwagi na najważniejsze - generalnie zastosowanie różnych opcji przed kompilacją jądra zmieniało wyniki benchmarków w naprawdę znikomy sposób. W dodatku kompletnym zaskoczeniem było dla mnie to, że również jądro z repozytorium Debiana nie tylko nie odstawało od reszty, ale nawet wygrało część testów. Co ciekawe ono jako jedyne zostało skompilowane w gcc 4.3, resztę kompilowałem w gcc 4.4 (powszechnie wiadomo, że nowsze kompilatory generują szybszy kod, co potwierdzają zresztą moje prywatne testy, z których może coś w przyszłości opublikuję). Ostatecznie jednak część zwycięstw jądra 2.6.32-2-amd64 należy przypisać temu, że jest nieco starsze od reszty testowanych, a w ostatnim czasie wprowadzanych jest sporo zmian w obsłudze systemu plików ext4 (którego używam), których efekty sprowadzają się do większego poziomu bezpieczeństwa i wiarygodności, ale także niewielkiego spadku szybkości działania. Mimo tych wszystkich niuansów różnice są na tyle małe, że zmuszają do zastanowienia - czy jest w ogóle sens kompilować jądro tylko po to, żeby je przyspieszyć?

<< Powrót

Komentarze:

vmario | 17:51 | 02.03.2010
Twoje obiektywne testy potwierdzające moje subiektywne odczucia -- rekompilacja jądra na PC-cie tylko w celu zwiększenia wydajności mija się z celem. Śmiem nawet twierdzić, że ręczna kompilacja całego systemu (vide Gentoo) daje tyle co nic. Nie mówię już o różnicach między systemem 32-bit a 64-bit -- przy pamięci poniżej 4GB to drugie to tylko mnóstwo dodatkowych kłopotów. Prawda jest taka, że to, czy jądro skorzysta z jakiegoś dodatkowego sprytnego rejestru w procesorze to sprawa drugorzędna. Na szybkość wstawania systemu pewnie o wiele większy wpływ ma optymalizacja skryptów startowych, a przy codziennej pracy decyduje raczej jakość programów w przestrzeni użytkownika, ewentualnie system plików. To oczywiście tylko moje prywatne opinie, nie poparte konkretną wiedzą i mające za sobą ledwie gram doświadczenia, ale obecnie ani mi przez myśl nie przejdzie rekompilować jądro na PC-cie. Zwłaszcza, że od blisko tygodnia próbuję skompilować Linuksa na ARM-a i mam już dość... :P
sadi | 21:29 | 02.03.2010
Kompilacja niektórych programów z różnymi opcjami kompilatora potrafi coś dać. Nie tak dawno temu kombinowałem w ten sposób ze źródłami POV-Ray\'a i uzyskałem gdzieś 5-10% przyspieszenie. Mimo to moje dotychczasowe doświadczenia pokazują jasno, że na przyspieszenie można liczyć tylko w niektórych programach, a nawet wtedy nie należy się spodziewać nie wiadomo czego (zgadzam się co do Gentoo ;) ). Skompilowanie jądra ma wpływ na szybkość startu systemu, ale pod warunkiem, że skorzystamy z okazji i pozbędziemy się initrd. U mnie daje to gdzieś 1,2 sekundy (na słabszych komputerach prawdopodobnie więcej). Dość powiedzieć, że są lepsze sposoby przyspieszania startu systemu. Zabawne, że wspominasz o kompilacji Linuksa na ARM. Kolega ze stancji (3 rok elektroniki) właśnie próbuje od dłuższego czasu wrzucić uClinuksa na płytkę z procesorem BF537 firmy Analog Devices. Nie chwaląc się, w ostatnich dniach trochę mu pomagam i jesteśmy już dość blisko sukcesu ;)
vmario | 12:07 | 06.03.2010
Choć to inna platforma, zapytam z ciekawości: czy sami kompilujecie tego Linuksa, a jeżeli tak, to jakich narzędzi używacie? Ja kompiluję wszystko od zera. Najpierw eksperymentowałem z OpenEmbedded i dystrybucją Angstrom, ale nic mi z tego nie wychodziło. Obecnie używam Buildroota, w którym udało mi się zbudować kernel 2.6.32.9 i BusyBoksa na uClibc. Wygląda na to, że zostanę właśnie przy Buildroocie, bo do systemów bez X-ów nadaje się chyba najlepiej.
sadi | 12:12 | 10.03.2010
My na tym Blackfinie kombinujemy tylko z uCLinuksem. Z gotowym jądrem udało się już postawić, skompilować jeszcze nie. Mieliśmy parę dni opóźnienia, bo kolega omyłkowo wymazał pamięć flash i męczyliśmy się jakiś czas z ponownym załadowaniem U-Boot\'a (co właśnie wczoraj udało się zrobić). Na razie nie jesteśmy tak daleko, żeby np. kombinować z BusyBoksem. Z resztą w ogóle nie wiem, co będzie dalej, bo to zależy od kolegi - to jego projekt.

Wszystkie przedstawione tutaj opinie należą do ich autorów i twórca strony nie ponosi żadnej odpowiedzialności za ich treść.


Imię/Ksywka (wymagane):

Strona WWW:

Wpisz tekst z obrazka (wymagane):

kod

Treść (wymagane):


W polu "Strona WWW" wpisywanie członu "http://" nie jest konieczne. Tagi (X)HTML wpisane w treści nie będą działać jako element strony, zamiast tego pojawią się w samym komentarzu. Komentarze obraźliwe, nie na temat lub niezgodne z prawem będą w miarę możliwości usuwane.

skiny: grey-tea green | light sky blue | carrot orange
some rights reserved | kanał informacyjny | admin | valid XHTML 1.0 | valid CSS | valid Atom 1.0