Notatki Šukasza Kidzi«skiego o wpªywie architektury komputera na

Łukasz Kidzińskiego (234151)
Wpływ architektury procesora na system operacyjny (wstęp)
Wprowadzenie
Mimo że wpływ architektury jest w oczywisty sposób kolosalny: w końcu każdy program pośrednio
lub bezpośrednio korzysta z udostępnionych przez procesor instrukcji, które są bardzo zależne od
producenta. Co więcej każdy producent wymyśla coraz to nowsze ulepszenia swoich architektur. W
rezultacie przed twórcami oprogramowania stoi trudne zadanie: z jednej strony muszą tworzyć
programy niezależne od architektury, a z drugiej powinni wykorzystać jak najwięcej
architektonicznych dobrodziejstw.
Sposobów podejścia do tego tematu jest mnóstwo. W niniejszym postaram się wyjść od genezy
systemu operacyjnego – zrozumienie tego skąd on się tak naprawdę wziął wyjaśni nam w jaki
sposób wpływa na niego architektura i dlaczego ten wpływ jest tak ogromny.
Notatki te są uzupełnieniem (a miejscami rozszerzeniem) do pierwszej części (tj. wstępu)
prezentacji.
Rozwój architektury
Dane dotyczące cen podzespołów komputerowych:
Cena mocy obliczeniowej:
1959: 1 GLOPS kosztowałby 10^12 dolarów (należałoby wykorzystać 17 milionów jednostek IBM
1620)
2008: 1 GLOPS kosztuje ok. 20 centów w konsoli Play Station 3
Kiedyś przed komputerem stawiano zupełnie inne zadania, a to dlatego, że nie śniło się ludziom
stawiać zadania trudniejsze.
Każdy program był pisany dokładnie pod architekturę i bynajmniej przepisanie go nie sprowadzało
się do przekompilowania. Pierwsze komputery nie potrafiły wykonywać wielu zadań jednocześnie.
Nie potrafiły nawet wykonać automatycznie jednego zadania po drugim.
I wtedy też pojawiła się potrzeba stworzenia systemu
operacyjnego. Nie był to jeszcze śliczny Windows Vista, lecz
przełączarka zadań, której mówiono „wykonaj A, a potem B”, a
ona to właśnie robiła.
Lata 60te – rozkwit systemów
Jeśli za początek ery komputerów uznamy początek lat 50tych to
twórcy systemów operacyjnych dość znacząco zaskakują nas już dekadę później. Wtedy bowiem
pojawia się CTSS – Compatible Time-Sharing System. I bynajmniej nie bez przyczyny w nazwie
pojawia się „Time-Sharing”.
System pozwala współdzielić czas procesora, ma swój scheduler (zaimplementowany jako kolejka
wielopoziomowa). W działaniu wspiera go architektura (zmodyfikowany mainframe IBM 7094)
–
Wydzielenie 5 z 32kb pamięci operacyjnej specjalnie dla jądra systemu (pierwsza pamięć
chroniona)
Pojawiają się pierwsze przerwania zegarowe dzięki którym można podzielić czas wykonywania
danego procesu.
–
Instrukcje wyłapywane przez system operacyjny (np. exit)
System też musi zarządzać urządzeniami zewnętrznymi – CTSS obsługuje 6 urządzeń (w tym do
112 „dalekopisów” tj. terminali).
Kilka lat później pojawia się Multics – przodek Unixa. Wraz z nim przychodzi idea znana skądinąd
do dziś – patrzenie na wszystko jak na plik. Umożliwiło to wprowadzenie trochę większej
abstrakcji, tj. kolejny krok w do uniezależnienia sprzętu od aplikacji użytkownika.
Pojawiają się też kolejne problemy ze strony architektury
Maszyny wspierały tylko segmenty pamięci o rozmiarze 1MB. Trzeba było wymyślić sposób
radzenia sobie z większą ilością danych. Z drugiej strony zadanie było ułatwione o tyle, że 1MB
rzadko był wtedy osiągalny.
Pojawia się też stos dla każdego programu i każdego trybu. Wiele pomysłów jest realizowanych
programowo, ale właśnie te pomysły starają się później realizować projektanci sprzętu.
Lata 80te – rozkwit sieci komputerowych
1971 - Ray Tomlinson wysyła pierwszego w świecie maila
10 lat później pojawia się rozproszony system operacyjny Novell Nerware, który rewolucjonizuje
podejście do systemu plików. Architektura client-server pozwala na „file sharing instead of disc
sharing”.
Barkley sockets – teraz już nawet pisanie wiadomości przez kabel to pisanie do pliku.
Kolejne abstrakcje w systemach operacyjnych znów coraz bardziej oddzielają sprzęt od aplikacji
użytkownika.
Innym ciekawym rozwiązaniem, które pojawiło się w tym okresie był Lisp machine.
Komputer którego głównym językiem był język Lisp. Warto mieć na uwadze, że systemy
operacyjne oprócz funkcji zarządzania pamięcią mają za zadanie zwiększenie abstrakcji dla
piszących aplikacje – nie chcemy już pisać w assemblerze. Powstają języki programowania.
Powstają kompilatory które potrafią dostosować kod do konkretnej architektury.
Lisp machine wymagał zarówno wsparcia ze strony sprzętu jak i ze strony systemu operacyjnego.
Pomysł stworzenia maszyny zorientowanej specjalnie na język funkcyjny wydaje mi się niezwykle
ciekawy. Niestety nie jest to tematem. Zainteresowanych odsyłam wstępnie do
http://en.wikipedia.org/wiki/Lisp_machine
Co ciekawe, trwają również prace nad maszyną dedykowaną dla Javy.
Lata 90te – komputery osobiste
Mija 40 lat od powstania pierwszych
komputerów. Szybki rozwój powoduje, że to
co mieliśmy w starych mainframe'ach
możemy postawić sobie na biurku (o ile owe
biurko jest wystarczająco solidne by
udźwignąć 8kg, a portfel wystarczająco
pojemny by kupić zabawkę za $2,495 Macintosh 128K).
Okazuje się, że komputer nie musi w kółko do mnożenia macierzy – sprawdza się nawet jako
narzędzie do rozrywki.
Z początku, w komputerach typu Atarii mamy to co mieliśmy w dawnych mainframe'ach, tzn.
–
jednozadaniowość
–
prosty interpreter języka (tym razem BASIC)
–
brak systemu operacyjnego, bo szkoda zasobów
Apetyt rośnie w miarę jedzenia
Im więcej człowiek wymaga od systemu, tym lepsza musi się stać architektura.
Im lepsza staja się architektura, tym więcej funkcji w systemie.
Im więcej funkcji w systemie, tym więcej chce otrzymać użytkownik.
I tak w koło Maćku.
System nie może rozdzielić czasu dopóki nie wymyślono przerwania zegarowego.
System nie chroni procesów dopóki nie wprowadzono trybu chronionego.
System nie wyświetla grafiki 3D dopóki nie wprowadzono GPU.
Z kolei braki w architekturze muszą być nadrabiane przez system operacyjny:
System walczy ze ślamazarnością I/O poprzez odpowiednie kompilowanie kodu.
System zarządza zasobami komputera, bo architektura sama sobie z tym nie poradzi.
System stanowi interface pomiędzy sprzętem, a użytkownikiem. Człowiek, który np. chce znaleźć
minimum funkcji użyteczności z reguły nie chce się uczyć assemblera.
Pamięć
Podaż taniej pamięci ma dość specyficzny wpływ na system komputerowy.
Z jednej strony mamy oczywiste korzyści:
–
duża pamięć operacyjna pozwala nam uruchomić więcej programów
–
duże dyski twarde powodują, że nie musimy zaprzątać sobie głowy usuwaniem plików
–
można również tworzyć wszelkiego rodzaju statystyki i indeksy pomagające w wyszukiwaniu
albo nawet w algorytmach schedulera/branch prediction itp.
Z drugiej strony wraz ze wzrostem wielkości dysku nie
rośnie tak gwałtownie szybkość przesyłania danych. W
rezultacie pojawia się problem zwany „Wait state” przy
którym to procesor czeka na dane i traci czas który mógłby
wykorzystać lepiej. Do tej kwestii jeszcze wrócimy.
Ilustracja 1: wzrost objętości dysków
twardych w latach 1990-2008
Jak to jest we współczesnych systemach?
Dziś systemy operacyjne wykorzystują wiele z udostępnionych udogodnień. Postaram się wymienić
najważniejsze z nich, a następnie zastanowimy się dlaczego nie są wykorzystywane wszystkie
mechanizmy sprzętowe.
System operacyjny wykorzystuje:
–
zegar systemowy
–
specjalne atomowe operacje, jak np. test-and-set
–
przerwania i wyjątki
–
ochronę pamięci
–
tryb chroniony
–
chronione instrukcje
–
komunikacja I/O
–
bit trybu
–
TLB
–
tablica stron
Oprócz tego system może wykorzystywać rozwiązania specyficzne dla danej architektury. Np.
TSS
Trzyma informacje o zadaniu. Jest wsparciem sprzętowym dla zmiany kontekstu
–
Rejestr procesora
–
Uprawnienia wejścia/wyjścia
–
Wskaźniki do stosów
–
Link do poprzedniego TSS
Wszystkie te informacje są wyspecyfikowane przez Intela. Tym niemniej linux nie tworzy TSS dla
każdego procesu, a jedynie dla każdego CPU
PAE
Pozwala systemowi odwoływać się do pamięci większej niż 4GB na komputerach 32-bitowych.
Szczegóły na ten temat, jak i ogólnie na temat zarządzania pamięcią znajdą się w trzeciej części
prezentacji (poświęconej architekturom 32-bitowym i 64-bitowym)
MMX
Zestaw instrukcji wprowadzony przez firmę Intel. Przeznaczony do szybkiego wykonywania
podobnych operacji arytmetycznych na zmiennych całkowitych. Przydatny do algorytmów
związanych z obsługą multimediów. Zwiększał np. graficzne możliwości systemu.
Wady: System operacyjny musi dla MMX „emulować” stos.
3DNow!
Odpowiedź AMD na MMX. Operacje zmiennoprzecinkowe.
Działają analogicznie do zwykłych operacji arytmetycznych, więc system nie musi o niczym
wiedzieć – ułatwia to zdecydowanie tworzenie aplikacji kompatybilnych z tą technologią.
SSE
Odpowiedź Intela.
System decyduje czy dać użykownikowi możliwość korzystania z dodatkowych instrukcji. Jeśli nie
wie, że takie instrukcje architektura udostępnia to nic się nie dzieje.
Jak to jest z trybem chronionym?
W Intelach oprócz trybu użytkownika i trybu
chronionego wprowadzono dwa kolejne tworząc
czterostopniowy system ochrony jądra. Tryby te są
jednak używane stosunkowo rzadko.
Są dwa powody:
–
zmiana trybu jest bardzo kosztowna. Źle
wykorzystane skakanie pomiędzy trybami
mogłoby prowadzić do kolejnego zmniejszenia
efektywności.
–
nie wszystkie architektury obsługują 4 tryby.
Drugi powód jest bardziej ogólny. Tłumaczy on również po części dlaczego w Linuxie nie korzysta
się z TSS. Jako, że linux (jak i dowolny inny system) stara się przede wszystkim zapewnić
porządaną abstrakcję, łatwiej jest go dostosować do podobnych architektur. Jeżeli większość z nich
obsługuje 2 tryby, a jedna obsługuje 4, łatwiej jest korzystać tylko z dwóch.
Warto w tym momencie zauważyć, że ciągłe dodawanie/zmienianie/usuwanie instrukcji
emulowanie jednych drugimi w celu zachowania zgodności i tym podobne operacje bardzo łatwo
mogą prowadzić do tego, by architektura stała się bardzo złożona.
I tak jest w istocie. Architekturę x86 uznaje się za architekturę CISC, czyli o złożonej liście
rozkazów.
RISC vs CISC
Generalnie rzecz biorą pierwsze architektury były RISC'ami głównie ze względu na to, że
stworzenie złożonych rozkazów było technicznie niedostępne. Z czasem, gdy chcieliśmy jak
największą liczbę zadań przenieść z człowieka na maszynę, pojawiły się złożone instrukcje które
czasami np. realizowały pętle. W apogeum złożoności instrukcji powstawały właśnie takie maszyny
jak Lisp machine.
Miało to oczywiście swoje zalety, ale szybko okazało się, że ma także wady. Otóż wydajność
instrukcji złożonej była niższa niż szereg odpowiadających jej instrukcji prostych. W rezultacie
znów zaczęto odchodzić od złożonych instrukcji – postanowiono ogłupić nieco procesor na rzecz
jego szybkości. Tak powstała architektura RISC.
Tym niemniej dla zachowania zgodności nie dało się zrezygnować ze wszystkich CISCów.
Zauważono jednak, że i tak bardziej opłaca się sprzętowo przetłumaczyć instrukcję złożoną na
proste. Tak powstały nowe procesory x86.
Architektury RISC zawdzięczają swoją siłę m.in. potokowaniu instrukcji. Pozwolę sobie nie
wyjaśniać na czym to polega, gdyż wszystkich nas już tego na studiach uczono.
Wait state
Na koniec chciałbym przytoczyć jeszcze kilka szczegółów na temat jednego z większych
problemów z którymi projektanci systemów muszą się borykać, a mianowicie z Wait state.
W jaki sposób staramy się mu zaradzić?
–
instruction prefatch (pobieranie instrukcji do cache'u zanim jest ona potrzebna)
–
przewidywanie rozgałęzień (tworzenie różnych statystyk skoków itp.)
–
wielowątkowość (gdy jeden czeka, drugi może liczyć)
–
wykonywanie niezależnych instrukcji
–
hardware scout
Ostatnia z wymienionych technik polega na uruchomieniu dalszego kodu programu przy czym nie
w celu pobrania dalszych danych, a raczej w celu przewidzenia ewentualnych przyszłych skoków –
wyniki są pomijane.
Podsumowanie
Jak widać architektura z systemem operacyjnym idą niezmiennie w parze od ponad 50 lat. Dobrym
przykładem na to, jak silnym (przynajmniej ekonomicznie) może być to połączenie jest przykład:
Intel + Microsoft
Drugim nasuwającym się wnioskiem jest to, że historia uczy nas trochę przyszłości. Możemy już
teraz spodziewać się, że moc obliczeniowa niedawnych mainframe'ów zawita do naszych domów,
zaś komputery o mocy dzisiejszych desktopów niedługo będziemy mieć w kieszeniach. W raz z
nimi pojawią się analogiczne systemy operacyjne.
Bibliografia:
http://en.wikipedia.org/
http://www.x86-guide.com/
http://siyobik.info/index.php?module=x86
http://developer.intel.com/products/processor/manuals/index.htm