RedHat Linux Dzisiejszy artykuł jest trochę ambitniejszy. Dla niektórych może wydać się nudny, innych może zainteresować. Nie będzie ciekawego filmiku przedstawiającego np. MAC OSX uruchomiony na Aspire One, albo dodania podgrzewacza do kawy podłączonego do portu USB i sterowanego przez serwer Apache i crontab (w sumie pomysł nie jest taki głupi, kiedyś może go przemyślę…). Artykuł jest o kompilacji (nie mylić z komplikacją) i optymalizacji oprogramowania do pracy z konkretnym modelem procesora….

Czy korzyści są wymierne? Na początek szczypta historii…

Dawno, dawno temu, kiedy pierwsze komputery zajmowały więcej miejca, niż standardowa komoda, oprogramowanie było pisane tylko w języku maszynowym, czyli potocznie zwanym asemblerze. Używając tego określenia mam na myśli zarówno rodzinę języków, jak i oprogramowanie do asemblacji (czyli swego rodzaju… komplilacji dla języków wysokiego poziomu – taka intepretacja może budzić sporo zgorszenia wśród niektórych bardziej ortodoksyjnych uczelnianych profesorów). Najprościej rzecz ujmując – jedno polecenie asemblera odpowiada jednemu rozkazowi procesora: jak podamy init 21, to zostanie wywołane przerwanie dwudzieste pierwsze; gdy wykonamy rozkaz mov al, 61h to wartość 97(D) zostanie załadowana do rejestru AL itd.
Już się zraziłeś i masz dość tego asemblera? Fakt – skomplikowane i wymaga sporej wiedzy o architekturze procesora – ale jak przewiniesz się przez uczelnię techniczną o profilu informatycznym, to z dużym prawdopodobieństwem będziesz znał to na pamięć…

No i właśnie z tego powodu powstały języki programowania i kompilatory – aby ułatwić ludziom życie (przynajmniej taka jest moja teoria). Cytując za Wikipedią:

Kompilator (ang. compiler) to program służący do automatycznego tłumaczenia kodu napisanego w jednym języku (języku źródłowym) na równoważny kod w innym języku (języku wynikowym) [1]. Proces ten nazywany jest kompilacją. W informatyce pojęciem kompilatora określa się najczęściej program do tłumaczenia kodu źródłowego w języku programowania na język maszynowy. Niektóre z nich tłumaczą najpierw do języka asemblera, a ten na język maszynowy jest tłumaczony przez asembler.

Co z tego wynika? Programista nie musi znać asemblera a kod z dużym prawdopodobieństwem można przenieść i dostosować do innej platformy. Przechodzimy więc do najbardziej interesującego nas zagadnienia – czyli pakiety. Jak już kiedyś pisałem, dostarczany z Aspire One Linpus obsługuje (po dokonaniu kilku modyfikacji) pakiety RPM. Pakiet to taka magiczna i wygodna rzecz – ktoś za nas skompilował program, napisał skrypty do instalacji, dezinstalacji, sprawdzania zależności (czasem program wymaga np. bibliotek dostępnych w systemie) i dodał jeszcze instrukcję. Piękna sprawa! No to teraz może wady:

  • pakiety przygotowuje się do konktetych dystrybucji Linuksa – ciężko jest więc użyć paczki DEB (Debian) w RedHat i na odwrót (chociaż już widziałem, że użytkownicy potrafią…),
  • pakiety są kompilowane najczęściej bez optymalizacji dla konkretnego modelu procesora (ma być pełna zgodność z x86 i koniec- jak dobrze poszperać, to znajdą się zmodyfikowane wersje pod procesory AMD).

W tym miejscu powoli zaczyna być jasne, czemu niektórzy administratorzy wolą sami kompilować kluczowe aplikacje – celem nie tylko jest dodanie nowych funkcji, czy wyłączenie zbędnych modułów, ale właśnie też optymalizacja oprogramowania.

W świecie systemów Linuksowych rządzi GCC. „GNU Compiler Collection” to zbiór kompilatorów dla różnych języków – poczynając od podstawowego C (gcc) i kończąc na Ada (gnat). Od czasu, kiedy tatuś Linuksa (pan Stallman) w ’87 roku opublikował pierwszą wersję nastąpiło wiele zmian w GCC – ale najważniejsze, że na dzień dzisiejszy są to kompilatory dla różnych architektur – Intel, PowerPC, Alpha itd.
Dokumentacja producenta procesorów w znaczącym stopniu umożliwia optymalizację konfiguracji kompilatora dla potrzeb konkretnej architektury.

Przechodzimy teraz do procesora, który jest wbudowany w Aspire One. Co można wyczytać w powyższym temacie na stronie producenta? Intel wydał swój zoptymalizowany kompilator „Intel C++ Compiler 10.1” dla C, C++ i języka Fortran. Czym firma się chwali w przypadku tego narzędzia:

„(…) automatic processor dispatch, vectorization, auto-parallelization, OpenMP*, data prefetching, and loop unrolling, along with highly optimized C++ templates for parallelism, math processing, and multimedia libraries.”

Celowo nie tłumaczę cytatu, ponieważ niektóre zwroty technicze nie powinny być tłumaczone. Wykorzystanie mocy procesora jest częściowo opisane w tym dokumencie.
Jak to się ma do Atom(owego) procesora – ciekawa informacja znajduje się na stronie http://softwarecommunity.intel.com:


Q: Which compiler optimization switch does specifically address optimizations for the new Intel(R) Atom(TM) Processor?
A: The architecture specific optimization switch is -xL.

The new Intel(R) Atom(TM) processors are in-order machines. The Intel® C++ Compiler models the Intel(R) Atom(TM) processor pipeline and execution flow, thus enabling it to produce code with the optimum instruction execution sequence for low-power IA.

All the user needs to do to enable the in-order instruction pipeline modeling is to use the option switch –xL along with all the other compiler options they may be using to optimize their code. This allows for reordering the generated machine instructions and thus minimize pipeline stalls.

Do testów można pobrać ICC ze strony Intela. Optymalizacja kompilacji z użyciem gcc to temat na inny artykuł, można po tym poczytaj na stronie projektu. Sama kompilacja poprzedzana jest konfiguracją i dostosowaniem do wymagań danego systemu – z tego też powodu rozpoczyna się proces od komendy ./configure. Dodając na początku tego pliku linijkę CC=’[ścieżka do ICC]/bin/icc’ informujemy kompilator o wsparciu sprzętowym dla konkretnego modelu CPU. Podczas samego procesu wprawne oko wyłapie interesujące nas komunikaty, które dotyczą wsparcia dla SIMD (przetwarzanie wielu strumieni danych w oparciu o jeden strumień rozkazów):

remark: LOOP WAS VECTORIZED
remark: LOOP WAS AUTO-PARALLELIZED

Teraz najważniejsze – co zyskujemy. Testy przeprowadzane przez użytkowników dają wyniki zwiększające wydajność ok. 10% (to oczywiście też jest zależne od rodzaju aplikacji i kodu, dodatkowo eksperymenty mogą potwierdzić jeszcze większy wzrost wydajności).
Nic, tylko czekać na gotowe paczki – fascynaci będą je tworzyć i udostępniąć publicznie. Czemu dzisiaj o tym napisałem? Firma Acer udostępniła źródła i paczki dla Aspire One. Obecnie na serwerze jest ok. 500 pakietów RPM.
Link do serwera ftp: ftp://guest@csdftp.acer.com.tw/Aspire_One_Linpus_Linux
Mirror lokalny ( ~1.3GB ): http://aspireone.pl/tools/Linux/Acer/csdftp.acer.com.tw/

Do poczytania:



 Subskrybuj (FeedBurner)