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
Nowa wersja kompiluj.rb sadi | 23:11 | 24.10.2011
Skrypcik do kompilacji jądra metodą Debiana ulepszyłem i poprawiłem już dość dawno temu, jednak zapomniałem go udostępnić na stronie. No cóż - lepiej późno, niż wcale. Najważniejsze zmiany:
  • dodana obsługa jąder z serii 3.0
  • ściąganie archiwów tar.xz, zamiast tar.bz2
  • kilka dodatkowych opcji (i pytań z nimi związanych)
  • poprawa obsługi wątków
  • od tej pory skrypt jest na licencji MIT

Pobierz

P.S. Ciągle mam parę pomysłów na zmiany, jednak będą musiały one poczekać - ostatnio bardziej siedzę w projektach elektronicznych, nie programistyczno-linuksowych.
komentarze (5)


Automatyzacja kompilacji jądra sadi | 18:36 | 25.03.2010
tux.png
Ostatnio przypomniałem sobie o języku Ruby. Przedwczoraj postanowiłem, że użyję go, aby zautomatyzować proces kompilacji jądra pod Debianem. To co zaczęło się od banalnego programiku, skończyło się na czymś trochę bardziej zaawansowanym. Tak wygląda komunikacja programu z użytkownikiem:
debian:/home/sadi# ./kompiluj.rb 2.6.33.1
Na ktorym pliku konfiguracyjnym chcesz bazowac?
1) /boot/config-2.6.32.8-sadi
2) /boot/config-2.6.33-sadi
2
Jaka dodac podwersje? (czlon dodawany za wersja jadra,
np. -sadi; mozesz niczego nie podawac)
-sadi
Utworzyc initrd? (t/n; uwaga: kompilacja bez initrd
wymaga odpowiedniej konfiguracji jadra)
n
Czy zainstalowac jadro, gdy juz sie skompiluje? (t/n)
t
Ciagle trwa sciaganie lub rozpakowywanie archiwum...

### włącza się menuconfig i użytkownik może skonfigurować
sobie co chce ###

Rozpoczac teraz kompilacje? (t - rozpoczyna kompilacje,
n - wychodzi z programu)
t
Program należy wywołać z konta roota, podając jako parametr wersję jądra, którą chcemy zainstalować. Chwilę po uruchomieniu program sprawdza, czy mamy w katalogu /usr/src odpowiednie archiwum (jeśli nie, to je ściąga), a następnie rozpakowuje je. Dzięki zastosowaniu wątków (klasa Thread) możliwa jest dalsza praca programu zanim źródła jądra zostaną pobrane. Skrypt zadaje kilka pytań dotyczących konfiguracji. Gdy zakończy się zarówno wątek ściągania i rozpakowywania, jak i wątek konfiguracji, program uruchamia menuconfig. Gdy z niego wyjdziemy, skrypt pyta, czy teraz przeprowadzić kompilację. Od momentu wpisania ”t” wszystko dzieje się automatycznie. Dodatkowo program jest w pełni głupoodporny, tj. nie powinien się wysypać niezależnie od tego co i gdzie wpisze użytkownik. Całość zajmuje tylko 120 linijek kodu i powinna być dość łatwa do zrozumienia, czy przerabiania.

Zapraszam do testowania!

Pobierz

Zależności:
  • Debian lub inna dystrybucja umożliwiająca kompilację jądra metodą Debiana
  • Ruby 1.8+
  • kernel-package
  • fakeroot
  • wget

komentarze (0)


Metody kompresji jądra sadi | 12:10 | 03.03.2010
tux.png
Podczas pisania wczorajszego wpisu zauważyłem, że w jądrze 2.6.33 pojawiła się opcja skompresowania go algorytmem LZO. Postanowiłem wykorzystać tę okazję, żeby sprawdzić jakie rzeczywiście różnice w czasie uruchamiania systemu powoduje zastosowanie każdego z możliwych do wyboru algorytmów. Jak wykonywałem pomiary? Po pierwsze, wyłączyłem automatyczne ładowanie się trybu graficznego (użyłem narzędzia sysv-rc-conf do tymczasowego wyłączenia startowego skryptu kdm). Po drugie, używałem stopera. To prawda, że jest Bootchart, ale mierzy on tylko co do sekundy, a to dla mnie za mała dokładność. Po trzecie, pomiar rozpoczynałem równocześnie z wciśnięciem entera w GRUB, a kończyłem wraz z pojawieniem się linijki zachęcającej do zalogowania. Po czwarte, dla każdego jądra zrobiłem 5 pomiarów i wyliczałem z nich średnie. Oto wyniki:

deb (Gzip)GzipLZMALZOBzip2
pomiar 1 [s]10,7210,0510,4710,4110,66
pomiar 2 [s]11,029,9110,1510,2110,43
pomiar 3 [s]10,829,7810,1410,3210,28
pomiar 4 [s]10,739,9510,2910,3610,32
pomiar 5 [s]11,049,8610,2110,2210,86
średnia [s]10,879,9110,2510,3010,51

Widać, że różnice są minimalne (uwaga - wartości średnie dalej są obarczone pewnym błędem). W każdym razie widać z nich, że stosowany do tej pory Gzip wygrywa z nowym LZO - czyli raczej nie ma sensu zamieniać. Jądro, które oznaczyłem jako "deb (Gzip)" jest wzięte z repozytorium Debiana. Umieściłem je w zestawieniu, żeby przy okazji pokazać różnicę jaką (u mnie) daje pozbycie się initrd. Jak widać są to okolice 1 sekundy.

Aktualizacja (15.03.10)

Podaję rozmiary jąder (w bajtach):
deb (Gzip)GzipLZMALZOBzip2
rozmiar [B]2 371 9043 050 9282 492 0003 328 0002 844 144

Tutaj zaskoczenia nie było - najmniejsze było jądro skompresowane algorytmem LZMA, a największe LZO. Wersja LZO jest większa od wersji Gzip o 9%, więc help w konfiguracji jądra mówi prawdę. Rozmiar jądra z repozytorium Debiana podałem, aby dane były kompletne. Różnica rozmiaru wynika z tego, że dla siebie wkompilowuję trochę dodatkowych rzeczy do jądra.
komentarze (6)


Opłacalność kompilacji jądra sadi | 00:19 | 02.03.2010
pts.png
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ć?
komentarze (4)


Testy JS w przeglądarkach sadi | 13:57 | 24.01.2010
Z okazji premiery Firefoksa 3.6 przed paroma dniami, oraz przedstawienia wersji pre-alpha Opery 10.50 parę tygodni wcześniej, postanowiłem przeprowadzić testy szybkości JavaScriptu w różnych przeglądarkach dostępnych na Linuksa. Od razu mówię (gdyby ktoś nie wiedział), że pod Debianem, Firefox nazywa się Iceweasel (Iceweasel 3.5.6 = Firefox 3.5.6). Do zestawienia z czystej ciekawości włączyłem również Konquerora, którego chyba mało kto używa jako przeglądarki.
Testy przeprowadziłem na 64-bitowym Debianie z własnoręcznie skompilowanym jądrem 2.6.32.3, na komputerze z procesorem Core 2 Duo E8400 i 4GB pamięci RAM. Oto wyniki:

Wykres wyników Peacekeepera i V8

Wykres wyników Sunspidera

Należy się parę słów komentarza. Przede wszystkim nie należy zbytnio ufać benchmarkom. Peacekeeper jest tworzony przez Futuremark, tę samą firmę, która robi 3DMarka. Sprawiają oni wrażenie ludzi, którzy znacznie bardziej troszczą się o fajny wygląd, niż miarodajność. V8 Benchmark Suite, został zdaje się napisany przez Google i jest używany przy kalibracji ich przeglądarki - Chrome. Pytanie czy można taki benchmark traktować poważnie. Natomiast wynikami Sunspidera chwalą się twórcy Opery 10.50. Czyżby optymalizowali kod pod jego kątem?
Co do wyników - widzimy, że za zwycięzcę uczciwie należy uznać Chrome. Jednak stosunkowo niedaleko za nim jest nowa pre-alpha Opery. Nieco z tyłu, na trzecim miejscu jest świeżutki Firefox 3.6. Wyniki dla dalszych przeglądarek są niejednoznaczne i można uznać swego rodzaju remis między stabilną Operą i starszym Firefoksem. Warto nadmienić, że Konqueror nie ukończył V8 w wersji 5. Błąd pojawiał się również w wersji 4 benchmarka. W wersji 3 Konqueror dostał 234 punkty, jednak nie powinno się tego wyniku porównywać z wynikami z wersji 5 benchmarka.
Po co nam w ogóle szybki JavaScript? Cóż, wszystko zależy od tego jakie strony się odwiedza. Szybkość JavaScriptu ma kluczowe znaczenie dla komfortu użytkownika przy pracy w aplikacjach internetowych, jak np. większość usług Google. Świetnym przykładem jest znajdujący się ciągle w fazie preview Google Wave, gdzie na prawdę da się odczuć różnicę pomiędzy korzystaniem z Firefoksa, a Chrome. Różnica jest prawdopodobnie jeszcze bardziej odczuwalna na starszych komputerach. Z drugiej strony, jeśli nie używasz takich stron, to przynajmniej na razie szybkość JavaScriptu nie ma dla Ciebie większego znaczenia.
Na koniec przedstawiam surowe wyniki, na bazie których powstały wykresy. Może komuś się przydadzą...

Peacekeeper Sunspider V8 Benchmark Suite
Chrome 4.0.249.43 5116 368.0ms +/- 2.8% 4889
Opera 10.50 pre-alpha 4328 292.6ms +/- 1.1% 3592
Opera 10.10 2067 3213.8ms +/- 0.5% 257
Opera 10.20 alpha 1 2025 3236.8ms +/- 0.6% 252
Firefox 3.6 2816 861.0ms +/- 0.7% 470
Iceweasel 3.5.6 1843 1858.4ms +/- 6.2% 319
Konqueror 4.3.2 1326 2339.6ms +/- 0.3% error

komentarze (0)


Labirynt 3D sadi | 21:27 | 17.06.2009
Dzisiaj pokażę Wam wynik pracy na potrzeby projektu, o którym wspominałem już wcześniej. Animacja trwa 3 minuty i renderowała się ok. 3 dni na podkręconym (3651 MHz) procesorze Core 2 Duo E8400. Dodam, że jak na standardy amatorskiej animacji to raczej krótko - trzeba było włożyć wiele wysiłku w to, aby trwało to tylko tyle. Ciągle z niektórych rzeczy nie jestem do końca zadowolony, ale zwyczajnie zabrakło czasu, żeby je ulepszyć. Pozostaje dodać, że licencja Creative Commons, którą objęta jest użyta muzyka, nakazuje mi poinformować, że jej autorem jest Matti Paalanen, a utwór nazywa się Hope for Rebirth.

Animację w średniej (dopiero po wciśnięciu przycisku HQ), jakości możecie zobaczyć tutaj:


Animację w dużej jakości (polecam) można pobrać z serwisu MegaUpload.
komentarze (4)


Przyspieszamy start Debiana - część 2 sadi | 14:55 | 11.06.2009
openlogo-100.png
Już dość dawno temu opisałem, w jaki sposób przyspieszyłem start Debiana o ok. 7 sekund. W ramach ostatnich dni pojawiło się jądro 2.6.30, które wprowadza kolejne zmiany mające na celu przyspieszenie bootowania. Pomyślałem, że to dobra okazja do kompilacji.
Zanim przejdę dalej, powinienem opisać, jak mierzę czas startu - zwłaszcza, że zmieniło się to od poprzedniego wpisu. Czas bootowania mierzyłem stoperem. Pomiar rozpoczynałem w momencie wciskania enter w GRUB'ie, a kończyłem w momencie pojawienia się linijki zachęcającej do zalogowania (wyłączyłem kdm). Czasy, które podaję w dalszej części tego wpisu, to średnie z trzech pomiarów.
Korzystając z okazji postanowiłem pozbyć się initrd, który podobno wydłuża bootowanie o ok. 1-1,5 sekundy. Wiele dystrybucji Linuksa używa initrd przy rozruchu systemu. Dzięki temu, mogą skompilować uniwersalne jądro, które jednocześnie będzie zajmowało mało miejsca. Nas uniwersalność nie obchodzi - z założenia kompilujemy jądro tylko dla siebie. Aby rezygnacja z initrd nie skończyła się na Kernel Panic, musimy wkompilować w jądro parę rzeczy. Przede wszystkim będzie to obsługa naszego dysku twardego, używany na partycji linuksowej system plików, oraz obsługa dysków SCSI (o ile Linux rozpoznaje nasz dysk np. jako sda, a nie hda). U siebie musiałem ustawić takie opcje:

General Setup > Initial RAM filesystem and RAM disk support [N]
Device Drivers > SCSI device support > SCSI disk support [Y]
Device Drivers > Serial ATA and Parallel ATA drivers > ATA SFF support [Y]
Device Drivers > Serial ATA and Parallel ATA drivers > Intel ESB, ICH, PIIX3, PIIX4, PATA/SATA support [Y]
File Systems > Ext3 journalling file system support [Y]