Dawno, dawno temu, prawie w odległej galaktyce – bo w Stanach Zjednoczonych – i prawie w czasach prehistorycznych, bo w późnych latach 60-tych, w rodzącej się do życia Krzemowej Dolinie zaczęły powstawać procesory oparte o krzem. Krzem, w odróżnieniu od germanu, doskonale znosił pracę w podwyższonej temperaturze. Tak zaczęła się ogólnoświatowa rewolucja, której świadkami jesteśmy dzisiaj.
Co ciekawe jednak, niewiele później, bo już we wczesnych latach 70-tych XX wieku, w Wielkiej Brytanii przemysł komputerowy również próbował przebić się do powszechnego użytku i przeciętnego użytkownika. Efektem tego było wiele mniej lub bardziej ciekawych innowacji. Z tych najciekawszych warto na pewno wspomnieć procesor Zilog (bit.ly/36tZBOJ) i oparty o niego komputer Spectrum Z80 (bit.ly/3lreFmw). Sam procesor był wstecznie kompatybilnym rozszerzeniem procesora Intel 8080, zbudowanym z myślą o relatywnie tanich komputerach przemysłowych. Z80 stał się jednak bardzo popularny w komputerach domowych, sprzęcie muzycznym, a nawet w zastosowaniach wojskowych.
Drugą, nie mniej ważną był równoległy rozwój koncepcji internetu. Równocześnie z Bobem Taylerem i J. C. R. Lickliderem ze Stanów Zjednoczonych, którzy zajmowali się ARPANET, Brytyjczycy również doszli do wniosku (bit.ly/3ktzkoH), że komutacja pakietów, czyli – mniej lub bardziej – po polsku, „przełączanie pakietów”, to lepsze rozwiązanie niż dedykowanie zasobów pod transmisję danych na stałe. Trzecią ciekawostką, pośrednio łączącą się z tym artykułem, była gra Elite. Symulator kosmicznego pirata i handlarza w jednym.
ARM stosuje w procesorach wiele rozwiązań niespotykanych w tradycyjnej architekturze x86. Mowa np. o bardzo długim buforze na kolejkę instrukcji. Procesory ARM tradycyjnie używają buforu na ok. 200-300 poleceń. Dzisiejsze procesory x86 używają buforów na 50-150. Drugim, unikalnym rozwiązaniem jest stosowanie w jednym procesorze wielu rdzeni różnych typów. Dzisiaj stosuje się różne kombinacje “bardziej wydajnych” i “mniej wydajnych” rdzeni (ARM nazywa je “Cortex”). Od 2×2 (2 szybsze i 2 wolniejsze) przez 2×4 (2 szybsze i 4 wolniejsze) po różne egzotyczne kombinacje typu 3×6. Oczywiście dynamiczne wykorzystanie rdzeni szybszych i wolniejszych wymaga odpowiednio dopracowanego kodu, ale daje rewelacyjne efekty w kontekście równoważenia wydajności i energooszczędności.
Gra była o tyle ciekawa, że w niewielkiej ilości pamięci RAM dostępnej w komputerach lat 80-tych (16kB i 32kB), udało się zmieścić cały zestaw galaktyk. Ponieważ pamięć była ograniczona i oczywiście brakowało w niej miejsca, autor – David Braben – zaprojektował algorytm, generujący świat gry po uruchomieniu, niejako “w locie”. Cała gra musiała zmieścić się bowiem w dostępnej wówczas pamięci komputerów popularnych w Wielkiej Brytanii BBC Micro (bit.ly/35sHERc) oraz Acorn Electron (bit.ly/2Uo16Z4). Efekt końcowy w ówczesnych czasach (a był rok 1984!) okazał się oszałamiający. W pamięci ówczesnych komputerów udało się dzięki temu zmieścić 2^48 galaktyk, każda ze swoim systemem planetarnym, zestawem cen na produkty i oczywiście nazwą wybraną ze specjalnych tablic. Kto pamięta jeszcze “absolwentów sztuk mięsożernych”? Te i inne historie o brytyjskiej innowacji opisano w doskonałej książce Backroom Boys (bit.ly/3nnhjua).
Czy RISC lub CISC ma aż takie znaczenie?
Czwartym obszarem innowacji – nie mniej ważnym, niż pozostałe i jednocześnie tematem tego krótkiego artykułu – była wymieniona już wyżej firma Acorn. Acorn tworzył od początku komputery dla zwykłego użytkownika, ale po drodze zbudował też cały przemysł wokół procesorów w architekturze RISC (Reduced Instruction Set Computer). W przeciwieństwie do architektury znanej m.in. z procesorów Intela, opartej o model CISC (Complex Instruction Set Computer), procesory RISC stworzono z założeniem, że to po stronie programisty leżeć będzie odpowiedzialność budowy złożonych programów. Natomiast sam procesor udostępni mu proste, ale jednocześnie bardzo szybkie, możliwe do łatwego zrównoleglenia i w końcu energooszczędne środowisko pracy. O ile w latach 70 i 80-tych trudno było wprost dostrzec zalety tych rozwiązań (poza środowiskami akademickimi), wraz z rozwojem rozwiązań mobilnych okazało się, że procesory RISC są strzałem w dziesiątkę.
Potencjał procesorów RISC ARM (najpierw Acorn RISC Machine a potem Advanced RISC Machine) do budowy urządzeń mobilnych został dostrzeżony bardzo szybko. Licencje ARM nabył m.in. Apple, od początku opierając swoją linię produktów – iPhone, iPad, iPod, iWatch – o procesory tej rodziny. Z czasem, Apple (podobnie jak wielu innych producentów) zaczęło samodzielnie rozwijać koncepcje starając się zaoferować coś, czego inni producenci od firmy ARM kupić nie mogli. Przykładowo w 2011 roku 32-bitowe procesory ARM były najpopularniejszą architekturą wśród systemów tzw. osadzonych. Dwa lata później ich łączna liczba przekroczyła 10 mld! Stało się tak, ponieważ inni producenci rozwiązań mobilnych (np. Samsung ze swoją serią urządzeń Exynos), też chętnie korzystali z energooszczędnego procesora i jego architektury. Dzisiaj w zasadzie wszystkie, liczące się na rynku urządzenia mobile pracują pod kontrolą procesorów ARM lub ich pochodnych. O ile producenci procesorów w architekturze CISC – zgodnych z x86 – wykonali przez ostatnie 40 lat tytaniczną pracę, do sukcesu w postaci prawdziwej energooszczędności jest jeszcze bardzo daleko.
Gdzie tkwi tajemnica procesorów ARM?
ARM stosuje w procesorach wiele rozwiązań niespotykanych w tradycyjnej architekturze x86. Mowa np. o bardzo długim buforze na kolejkę instrukcji. Procesory ARM tradycyjnie używają buforu na ok. 200-300 poleceń. Dzisiejsze procesory x86 używają buforów na 50 do 150 instrukcji, a Apple stosuje kolejki estymowane na 500-600 instrukcji. Taka konstrukcja pozwala dobrze “przygotować” procesor na równoległe wykonywanie poleceń.
Tradycyjne systemy operacyjne, takie jak Linux czy Windows, nie muszą zdążyć w reżimie czasu wykonać swoich zadań. Jeśli system się “spóźni” i nie przerwie źle napisanego fragmentu kodu odpowiednio szybko, z reguły nie dojdzie do prawdziwej katastrofy. Dzieje się tak dlatego, że te systemy operacyjne tworzone są jako zoptymalizowane do interakcji z ludźmi – a ludzie reagują nieporównywalnie wolniej niż komputery i są nieporównywalnie mniej spostrzegawczy. Natomiast systemy czasu rzeczywistego sterują procesami przemysłowymi lub elementami infrastruktury krytycznej, w której reżim jednostki czasu i przewidywalny czas wykonania każdego polecenia jest najważniejszy.
Drugim, unikalnym rozwiązaniem jest stosowanie w jednym procesorze wielu rdzeni różnych typów. Dzisiaj stosuje się różne kombinacje “bardziej wydajnych” i “mniej wydajnych” rdzeni (ARM nazywa je “Cortex”). Od 2×2 (2 szybsze i 2 wolniejsze) przez 2×4 (2 szybsze i 4 wolniejsze) po różne egzotyczne kombinacje typu 3×6. Oczywiście dynamiczne wykorzystanie rdzeni szybszych i wolniejszych wymaga odpowiednio dopracowanego kodu, ale daje rewelacyjne efekty w kontekście równoważenia wydajności i energooszczędności. Jeśli spróbujemy w tym względzie porównać procesory budowane w tej architekturze i np. w architekturze x86 (dla ułatwienia skupmy się tylko na procesorach przeznaczonych do rozwiązań “mobilnych”)… nie ma co porównywać. W najlepszym przypadku efektywne zużycie energii jest 5-10 krotnie wyższe, a wydajność… ta sama!
Dla przykładu, najnowszy procesor Apple’a do urządzeń mobilnych – A14 bazuje na licencji uzyskanej od ARM i produkowany jest przez TSMC w technologii 5nm, z efektywnym TDP (Thermal Design Power) – w uproszczeniu ilość energii, którą system chłodzenia musi rozproszyć z procesora by zapewnić mu stabilną pracę – ustawionym na 5W. Dla porównania, AMD produkuje najnowsze procesory Ryzen w technologii 7nm, podczas gdy Intel – pogrążony w stagnacji – został w ciągu ostatniego roku daleko w tyle i dopiero we wrześniu i październiku ogłosił pierwsze procesory w technologii 10nm.
Proces wykonania ma fundamentalne znaczenie dla zapotrzebowania procesora na energię, a w efekcie ilość odprowadzanego ciepła oraz zużycie baterii. Procesor A14 – i najnowszy, ogłoszony dopiero M1 znajdujący się w najnowszych MacBookach – dotrzymują bez problemu kroku biurkowym, dużo bardziej energożernym procesorom Intela (i7, 1185G7, 26W TDP) oraz AMD (Ryzen 5950X, 49W TDP). Apple wykonał ogromną pracę optymalizując architekturę procesorów ARM na własną rękę, poza gotowcami dostarczanymi przez sam ARM, choć zaczął od bardzo dobrej i wdzięcznej do optymalizacji architektury.
64-bity w urządzeniach mobilnych
Kolejnym elementem związanym z unikalną architekturą procesorów ARM jest kwestia 64-bitów. Dla laika wybierającego nowy komputer czym więcej bitów tym “lepiej”. O ile część z czytelników pamięta jeszcze pewnie noce spędzone z ulubionym 8-bitowcem (ja z Atari 800XL), o tyle przez ostatnie parę lat z reguły mieliśmy do czynienia z 32-bitowymi procesorami w urządzeniach mobilnych i 64-bitową architekturą komputerów stacjonarnych. Działo się tak znowu dlatego, że o ile 64-bity wydają się “lepsze” i pozwalają obsłużyć więcej pamięci, w urządzeniach mobilnych oznacza to większe zapotrzebowanie na energię. Pamięć trzeba zasilić i podtrzymać jej zawartość, więc wracamy do trudnego kompromisu w gospodarce energią – czy dać użytkownikowi 64-bitowy procesor i 6 GB RAM w jego telefonie, czy 32-bitowy procesor i “tylko” 4 GB?
Dla firmy ARM 64-bity nie są szczególną nowością. ARM produkował 64-bitowe wersje procesorów już w 2011 roku (ARMv8). Co ciekawe, uniknął problemów innych producentów – MIPSa z ich R4000, DEC z procesorem Alpha czy Intela i Suna. Ich architektury zakładały całkowite odejście od dotychczasowego dziedzictwa procesorów 32-bitowych. Oznaczało to, że budowanie nowych aplikacji (nie mówiąc już o przenoszeniu czy zapewnieniu wstecznej kompatybilności ze starymi) było drogą pod górkę. Można powiedzieć, że AMD uratował cały rynek konsumencki, a potem korporacyjny, budując architekturę x86-64 oraz zapewniającą wsteczną kompatybilność z dotychczasową architekturą 32-bitową Intela. ARM poszedł krok dalej niż AMD. Zapewnił, że ten sam procesor może wykonywać zarówno kod 32-bitowy, jak i 64-bitowy. Ułatwiło to migrację, a jednocześnie pozwoliło zachować najważniejsze zalety, w tym energooszczędność. Dzisiejszy użytkownik najnowszego smartfonu już nie przejmuje się czy jego aplikacja pracuje w architekturze 32- czy 64-bitowej, a czas pracy na baterii znacząco się wydłużył. Ale ARM stosując nowatorskie podejście do zapewnienia wstecznej kompatybilności, zapewnił producentom oprogramowania i rozwiązań sprzętowych stabilną platformę do prowadzenia biznesu. Jest to kluczowe w utrzymaniu pozycji rynkowej.
ARM ogłosił nową wersję procesorów serii ‘R’ przeznaczoną do pracy w systemach czasu rzeczywistego, posiadających pełnoprawną jednostkę MMU (Memory Management Unit) i w końcu zbudowanych w architekturze 64-bitowej. Wprowadzenie MMU oznacza, że na tych procesorach również będzie mógł pracować “normalny” system operacyjny, np. Linux. To doskonała wiadomość dla producentów rozwiązań dla Internetu Rzeczy. Linux jest tu najpopularniejszym rozwiązaniem i co prawda może pracować bez MMU, ale w bardzo uproszczonej i w zasadzie nie rozwijanej już wersji (linie 2.0, 2.2 i 2.6).
Z ciekawostek warto w tym momencie wspomnieć, że królujący dzisiaj w tysiącach zastosowań komputer Raspberry Pi (bit.ly/3ltnEDE), oparty jest o architekturę wielu rdzeni ARM Cortex budowaną na licencji przez Broadcom. System w chipie SoC (System on a Chip) BCM2711 składa się z 4 rdzeni ARM Cortex A72 pracujących w architekturze 64-bitowej i dodatkowo procesora graficznego VideoCore VI 3D pracującego w architekturze 32-bitowej. Kolejną, wartą wspomnienia ciekawostką, udowadniającą, że procesory RISC to nie tylko energooszczędność i urządzenia mobilne, jest fakt, że od czerwca tego roku pierwsze miejsce na liście superkomputerów zajmuje rozwiązanie oparte o procesory ARM A64FX. Znajdujący się w Japonii Fugaku. Ten superkomputer wykonany przez firmę Fujitsu osiągnął spektakularną wydajność 416 Pflop/sekundę, bijąc poprzednika prawie 3-krotnie!
ARM serii R i nowe możliwości, jakie oferuje
W urządzeniach mobilnych spotykamy generalnie procesory budowane na licencji ARM z serii ‘A’ (Cortex-A) w różnych wersjach. Na początku września tego roku ARM ogłosił nową wersję procesorów serii ‘R’ przeznaczoną do pracy w systemach czasu rzeczywistego, posiadających pełnoprawną jednostkę MMU (Memory Management Unit) i w końcu zbudowanych w architekturze 64-bitowej. Brak jednostki MMU poprzednie generacje procesorów nadrabiały prostszą wersją MPU (Memory Protection Unit) i nie było to generalnie postrzegane jako wielka wada. Systemy czasu rzeczywistego RTOS (Real-Time Operating Systems) i tak polegają na prostym, przewidywalnym kodzie bez “udziwnień”. Jednak wprowadzenie MMU oznacza, że na tych procesorach również będzie mógł pracować “normalny” system operacyjny, np. Linux. To doskonała wiadomość dla producentów rozwiązań IoT. Linux jest tu najpopularniejszym rozwiązaniem i choć może pracować bez MMU, to w bardzo uproszczonej i w zasadzie nie rozwijanej już wersji (linie 2.0, 2.2 i 2.6).
Procesory ARM serii R stanowią dzisiaj 85% rynku kontrolerów pamięci masowych, mogą być też stosowane do innych tego typu zastosowań. Przykładami systemów klasy RTOS są produkty, takie jak QNX, VxWorks czy nasz rodzimy Phoenix RTOS (bit.ly/2Umg0Pk). Rozwija go – działająca od 1999 roku – firma Pawła Pisarczyka Phoenix Systems (phoenix-rtos.com), który nie tylko zbudował od podstaw ten system, ale obecnie sprzedaje używające go urządzenia z sukcesami na całym świecie.
Systemy czasu rzeczywistego i te ogólnego przeznaczenia
Tradycyjne systemy operacyjne, takie jak Linux czy Windows, nie muszą zdążyć w reżimie czasu wykonać swoich zadań. Jeśli system się “spóźni” i nie przerwie źle napisanego fragmentu kodu odpowiednio szybko, z reguły nie dojdzie do prawdziwej katastrofy. Dzieje się tak dlatego, że te systemy operacyjne tworzone są jako zoptymalizowane do interakcji z ludźmi – a ludzie reagują nieporównywalnie wolniej niż komputery i są nieporównywalnie mniej spostrzegawczy. Nie sterują procesami przemysłowymi lub elementami infrastruktury krytycznej, w której reżim jednostki czasu i przewidywalny czas wykonania każdego polecenia jest najważniejszy.
Systemy czasu rzeczywistego, bo o nich mowa, to rozwiązania dedykowane do zastosowań, w których wystąpienie różnicy opóźnienia w wykonaniu operacji (latency i jitter) może spowodować katastrofalne skutki. Tego typu systemy często korzystają z architektur CISC, ponieważ daleko prościej kontrolować w nich kod programu a zatem i sterowane nimi procesy przemysłowe, np. zawory gazu, przepływ prądu, nawigację satelity czy system kontroli lotu. Procesory zdolne napędzać system czasu rzeczywistego pracują nie tylko w przemyśle, ale też w sprzęcie wysyłanym w kosmos. Sonda Pathfinder, wysłana przez NASA na Marsa czy Solar Orbiter wysłany przez Europejską Agencję Kosmiczną pracują właśnie pod kontrolą systemów czasu rzeczywistego. Ale to już temat na zupełnie inny artykuł…
Łukasz Bromirski,
Senior Product Manager, Security BU, CCIE/CCDE w Cisco Systems w Polsce
