W związku z trwającą właśnie Olimpiadą w Pekinie postanowiłem jeść mniej cukierków. Wierzę, że dzięki tej manifestacji obrony życia, Chiny zaczną respektować prawa człowieka.
Ten wpis jest nawiązaniem do wpisu Bluszcza, który postanowił wyłączyć jeden z większych serwerów Jabbera (jabberpl.org) w Polsce na czas Igrzysk. Gratuluję rozwagi!
→ 3 CommentsTags: World Wide Web
Jutro, tj. 8.08.08 zostanie wydana wersja 2.2 frameworka Kohana. Prace nad wersją 2.2 trwały około pół roku. Trudno powiedzieć, by był to czas stracony. Świadczy o tym dużo commitów na SVN i nowa funkcjonalność.
Jedną z nowych rzeczy jest napisany całkowicie od nowa ORM (object-relational mapper). Poprzednia wersja miała „nienaprawialny” błąd, który powodował, że nie można było ograniczyć ilości pobieranych pól z powiązanych tabel relacji many to many. Ponadto zoptymalizowano nazwy metod – dotychczas większość metod była wywoływane przez powolne __call().
Będąc przy temacie wydajności, to Kohana 2.2 przyśpiesza ze względu na tzw. „internal cache”. Od teraz wszystkie pliki konfiguracyjne są serializowane, przez co nie trzeba ich ładować po kolei. Zwracam tutaj uwagę na kaskadowość systemy plików Kohany, tzn. że najpierw plik konfiguracyjny jest szukany w application/config, potem w modules/config, a na końcu w system/config. W większym projekcie wykorzystuje się często więcej niż 20 plików konfiguracyjnych, a szukanie plików na dysku zabiera cenne sekundy. Co więcej, rezultaty metody find_file() również są umieszczane w pamięci podręcznej. Tymi optymalizacjami Kohana przyśpieszyła trzykrotnie na moim domowym komputerze.
Wszystkich zainteresowanych tym, co nowe w Kohana 2.2 odsyłam na bugtrackera projektu.
→ 2 CommentsTags: KohanaPHP
Na rynku procesorów dla komputerów klasy PC swoje miejsce już dawno znalazły procesory tzw. dwurdzeniowe, a procesory czterordzeniowe stają się coraz tańsze. Procesor wielordzeniowy to de facto układ kilku oddzielnych procesorów o współdzielonej magistrali. Rodzi się pytanie, czy procesor n-rdzeniowy wykona szereg operacji n razy szybciej niż jeden procesor. Jak łatwo się domyśleć, odpowiedź brzmi “nie, jest wykona”.
Oprogramowanie nie jest idealne i nie jest przystosowane do obsługi wielu procesorów. Większość wykorzystywanych przez nas algorytmów ma charakter sekwencyjny, tzn. aby wykonać następny krok, trzeba zakończyć poprzedni. Nawet gdy programista poprawi algorytm tak, aby korzystał z wszystkich procesorów, nigdy nie osiągnie stuprocentowej skuteczności. W praktyce, ta część programu, której nie daje się zrównoleglić wynosi co najmniej 10%. Czy więc procesor 100-rdzeniowy jest tylko 10% wolniejszy od 100 osobnych procesorów? Kolejny raz odpowiadam “nie”.
Gene Amdahl sformułował prawo dotyczące wyznaczania maksymalnego przyśpieszenia programu równoległego w środowisku wieloprocesorowym.
n to liczba procesorów, a s to procent części sekwencyjnej programu.
Wzór interpretujemy w taki sposób, że zawsze istnieje nierównoległa część programu, w której trzeba oczekiwać na wynik poprzedniej operacji. Niemożliwe staje się więc wtedy przekazanie kolejnego rozkazu innemu procesorowi.
Poniżej przedstawiam teoretyczne przyśpieszenie programu w stosunku do systemu jednoprocesorowego na systemach o różnej ilości procesorów. Wartość dla nieskończenie wielu procesorów została obliczona z granicy funkcji. Testuję kilka programów o różnym procencie zrównoleglenia. Wartość liczbowa wyraża przyśpieszenie w stosunku do systemu 1-procesorowego.
| % sekwencyjności | 15% | 10% | 5% | 0,1% |
| 1 procesor | 1 | 1 | 1 | 1 |
| 2 procesory | 1,7 | 1,8 | 1,9 | 2 |
| 4 procesory | 2,8 | 3,1 | 3,5 | 4 |
| 8 procesorów | 3,9 | 4,7 | 5,9 | 7,9 |
| 20 procesorów | 5,2 | 6,9 | 10,3 | 19,6 |
| 100 procesorów | 6,3 | 9,2 | 16,8 | 91 |
| nieskończenie wiele | 6,7 | 10 | 20 | 1000 |
Jak widać, potencjalnie niewielki procent kodu, który nie daje się wykonać równolegle ma bardzo poważne skutki w wydajności programu na większej ilości procesorów. Nawet 99,9% równoległości programu spowoduje teoretycznie wzrost szybkości maksymalnie tysiąckrotnie.
Popatrzmy teraz na benchmark, aby odnieść te teoretyczne obliczenia do rzeczywistości. Bierzemy pod uwagę procesory Phenom X3 8750 oraz Phenom X4 9750. Są one idealne do tego porównania, ponieważ różnią się tylko i wyłącznie ilością rdzeni, podczas gdy częstotliwość taktowania, czy ilość pamięci podręcznej jest taka sama.
Jak widać, w żadnym z testów procesor trzyrdzeniowy nie jest półtora razy szybszy od dwurdzeniowego, choć potencjalnie tego byśmy oczekiwali. Jest to potwierdzenie, że rzeczywiście programy testujące nie są do końca równoległe. Przy okazji oceniłem program WinRAR, aby określić, w jakim stopniu algorytm kompresujący jest napisany równolegle. Wynik to ok. 90%.
W teście nie brałem pod uwagę strat wydajności wynikających z konstrukcji sprzętu, np. zapychania się magistrali między procesorami, problemów z zachowaniem spójności danych w poszczególnych L1 cache z pamięcią RAM, czy podziałem wątków na procesory (system operacyjny).
Powiązane:
→ 1 CommentTags: Technika
