Precz z Intelem! Czy przesiadka na ARM jest możliwa? Cz. II: zyski, straty, możliwości…

Precz z Intelem! Czy przesiadka na ARM jest możliwa? Cz. II: zyski, straty, możliwości…
Po wstępie historycznym trochę przemyśleń co Apple, my (programiści i oczywiście użytkownicy) możemy stracić lub zyskać przez hipotetyczne porzucenie architektury x86 na rzecz ARM oraz dlaczego tak może się stać.



Musieliście tak długo czekać na drugą cześć ponieważ:
Wyniki moich doświadczeń znajdziecie niżej.
Tu możecie poczytać jak kilka razy, już wcześniej Apple poradził sobie z takimi zmianami architektury stosowanych procesorów.

Na początek

Od razu zaznaczam, że obecnie procesory ARM nie są jeszcze superwydajne bo po prostu nie muszą. Są stosowane w dziedzinach gdzie ważniejsza jest energooszczędność (urządzenia mobilne) i/lub niezawodność (systemy wbudowane). To tak „awansem” abyście dotrwali końca wpisu.

W przerwie między obiema częściami wpisu o ARM pojawiła się kolejna seria plotek o tej hipotetycznej zamianie architektur procesora więc wygląda na to, że z tematem „wstrzeliłem” się w odpowiedni moment ;-)

Użytkownik

Większość użytkowników ma w głębokim poważaniu to jakiej architektury procesor jest stosowany w układach w ich komputerach. Często nie mają pojęcia co tam jest (wiem, bo czasem podpytuję klientów korzystających z mojego Faqt'a do faktur). Dla nich ważnie jest aby na komputerze odpowiednio szybko działały programy jakich potrzebują, system był stabilny, a komputer wart swojej ceny (lub odwrotnie).

Korzyści

Na początku to będą lżejsze, dłużej pracujące na baterii MacBooki (Air), które wcale nie muszą być powolniejsze od obecnych (pod pewnymi warunkami). Potem mogą to być inne komputery również te z segmentu pro (spokojnie… będę to motywował niżej). Kolejną zaletą mogą być niższe ceny komputerów, przynajmniej tych „nie pro”.

Bardzo ważnie może być też zwiększenie niezawodności systemu i programów działających na układach ARM ze względu na ich prostszą architekturę wewnętrzną i zgrabniejszy zestaw instrukcji.

Problemy

Mogą być chyba tylko dwa. Pierwszy duży czyli dostęp do programów w okresie przejściowym. Drugi mi. dla mnie błachy czyli brak możliwości prostego uruchamiania programów z Windows (problemy z wirtualizacją, brak Boot Camp).
Za czasów PowerPC brak możliwości uruchamiania Windowsa specjalnie nie przeszkadzał… jak ktoś bardzo potrzebował to miał narzędzia jak VirtualPC. Pod nim działał nawet Windows (choć zauważalnie wolniej). Jednak brak dostępu do programów z jakich korzystaliśmy na co dzień może być dyskwalifikacją.

Nie wiadomo też, jak szybko powstaną odpowiednie wersje Java, SQL czy Flash (choć mam nadzieję, że Flash zostanie całkiem zapomniany już niebawem). Są to środowiska tworzone przez firmy niezależne od Apple i tylko od ich woli, kalkulacji opłacalności i siły perswazji Apple, zależy czy zostaną dostosowane do hipotetycznych nowych komputerów z ARM w środku.

Apple

Ta firma już dwa razy stawała przed wyzwaniem zmiany architektury procesorów jakie stosuje (o czym pisałem w części I). Za pierwszym razem (Przejście z Motoroli na PowerPC) była to konieczność. Motorola kończyła rozwój linii M68xxx. Za drugim razem (z PowerPC na Intela) powód był bardziej „błahy” i głównym (choć nie jedynym) jego elementem był brak jednocześnie wydajnych i energooszczędnych układów PowerPC.

Zyski

Niezależność… Apple nie będzie musiało czekać na to co nowego pojawi się w świecie x86. Nie będzie się też musiało dzielić tymi nowościami z resztą komputerowego światka. Opracowując jednostki centralne dla własnych potrzeb będzie mogło dokładniej dopasować je do danego sprzętu oraz znacznie dłużej utrzymywać w tajemnicy nowości jakie szykuje. Jednostkowa cena wykonania „procesora” przy skali zamówień jakie Apple składa, również będzie znacznie niższa. Oczywiście dojdzie koszt opracowania nowego układu ale nie po to Apple kupowało (w ciągu kilku ostatnich lat) firmy zajmujące się projektowaniem i produkcją mikroprocesorów. Zresztą już zakupy nie poszły na marne. W iPhonach i iPadach mamy piątą generację procesorów opracowanych w Apple (czwartą w której Apple nie stosowało licencjonowanych rdzeni, a tworzyło własne zgodne z ARM).

Problemy

Największym wyzwaniem będzie „namówienie” programistów i firmy wydające oprogramowanie na OS X do szybkiego dostosowania swoich aplikacji dla nowej architektury. Oczywiście Apple musi zapewnić wszystkie możliwe narzędzia (XCode) aby takie przejście ułatwić. Dobrze by było aby udało się jak przy poprzednich zmianach architektury (zobacz wpis: Precz z Intelem! Czy przesiadka na ARM jest możliwa? Cz. I: Historia) opracować programowy emulator dla kodu x86. Spokojnie… nie odpalajcie jeszcze sowich „hejtomatów”… niżej napiszę dlaczego jest na to szansa.

Programiści

Programiści są z natury leniwi… jeżeli czegoś nie muszą zrobić to będą się ociągać. Dlatego Apple już teraz stosuje „bat” w postaci wymuszania projektowania premierowych i dostosowywania istniejących programów umieszczonych w App Store do nowych systemów i architektur procesora. Przejście na układy 64-bitowe w iPhonach i iPadach nie było całkiem bezbolesne i od niektórych programistów wymagało trochę więcej pracy niż „przestawienie wajchy” w XCode na kod 64–bit. Dlatego już niebawem Apple zacznie wymuszać kompilowanie na 64-bit i iOS 8 we wszystkich programach i aktualizacjach zgłaszanych do App Store. Albo się wydawca programu dostosuje, albo nie umieści programy w AS.

758450b2-63ca-490a-98bc-228bc6c42d1d

Aktualne ustawienia architektur w programie dla iOS. XCode generuje trzy wersje kodu programu na trzy architektury. Dwie podobne 32–bitowe: ARMv7 i ARMv7s oraz 64 bitową: ARM64

Korzyści

W zasadzie długo myślałem i niewiele wymyśliłem. Docelowo mogą to być lepsze i bardziej niezawodne narzędzia programistyczne. Za czasów gdy programowało się w kodzie maszynowym (assemblerze), co zdarzało mi się jeszcze w 1994 roku (Amiga), ważne było jak „łatwy” i poukładany jest kod maszynowy danej architektury. Teraz przewaga ARM nad Intelem (ARM ma pięknie przemyślaną architekturę i brak „ogona” zgodności z 8-16 bitowymi procesorami z lat 70 XX w.) bezpośrednio nie będzie doceniona przez większość programistów.
Największą realną korzyścią może być wygrana w „wyścigu” kto pierwszy dostosuje swoją aplikację do ARM. W dziedzinach gdzie jest spora konkurencja zwycięzca może dużo zyskać.

Problemy

W najlepszym wypadku gdy dana aplikacja jest od dłuższego czasu tworzona za pomocą XCode w którymś, z zalecanych przez Apple językach (C, ObjC czy teraz Swift), a programiści nie stosowali „sztuczek”, wystarczy zmiana ustawień przy kompilacji. Jeżeli jednak były stosowane sztuczki lub zostały użyte obce biblioteki binarne konieczne będzie grzebanie w kodzie i odczekanie aż dane biblioteki zostaną dostosowane do ARM (lub zastąpienie ich innymi rozwiązaniami).

Jeszcze gorzej wygląda sytuacja gdy uchował się jakiś projekt tworzony za pomocą innych narzędzi niż XCode od Apple. Wtedy jeżeli nie zostanie ono dostosowane do ARM konieczne będzie przeniesienie całego projektu na XCode. Ale to już w zasadzie podczas przejścia z PowerPC na Intela było przerabiane. Wtedy nastąpiła pierwsza fala „przymuszania” do używania XCode.

9597d451-d57f-4699-b33c-1144af9c45f6

Już teraz programy na obecne „Intele” zawierają dwie wersje kodu. Jedna dla 32–bitowych Inteli i jedna dla 64–bitowych. Po przejściu na ARM dojedzie trzecia… prawdopodobnie ARMv64 lub nowsza.

Zyski, straty: podsumowanie

Użytkownicy typowi czyli zadowalający się popularnymi aplikacjami nie powinni zbyt boleśnie odczuć tej ewentualnej zmiany. Gorzej będą mieli użytkownicy „pro” lub nietypowi posługujący się specjalistycznym czy naukowym oprogramowaniem lub korzystający ze specjalnych dodatków do systemu. Po okresie przejściowym na pewno wzrośnie ogólna wydajność pracy z programami i systemem oraz niezawodność systemu i aplikacji.

ARM… to ramie silne jest!

Jak we wstępie napisałem, procesory w architekturze ARM są jakie są bo na razie nie muszę być lepsze (wydajniejsze). Teraz mają być energooszczędne (i co za tym idzie nie grzać się zbyt mocno) oraz niezawodne. I takie właśnie są.

Najważniejsza bariera jaką był brak 64–bitowej architektury została pokonana już 2 lata temu i to ze znaczącym udziałem Apple. Teraz czas na zwiększenie wydajności, między innymi tradycyjnymi metodami jak zwiększenie taktowania czy ilości rdzeni procesorów.

Znów ciut historii

Procesory ARM powstały jako koprocesory i potem serca komputerów osobistych firmy Acorn.

Pod koniec lat 80, Apple rozpoczął współprace z firmą Acorn i razem z nią oraz VLSI Technology założyło Advanced RISC Machines Ltd (obecnie ARM Holdings). Wspólnie opracowany procesor ARM610 został użyty przez Apple w słynnym protoplaście wszystkich „padów” – Newtonie. Czyli Apple już ponad 20 lat temu „maczał palce” przy projektowaniu architektury ARM. Po zamknięciu przez Jobsa projektu Newton Message Pad (1998 r.) w 2007 roku procesory ARM znów wróciły do łask u Apple w iPhonach.

Pisząc „procesory ARM” stosuję pewnie uproszczenie. ARM nie produkuje procesorów, a jedynie licencjonuje architekturę (np. dla Apple) oraz projekty rdzeni (Apple już projektuje własne). Apple sam też nie produkuje „swoich” układów. Własne projekty (oparte o architekturę ARM) zleca do wykonania innym, między innymi Samsungowi.

Siła prostoty

W przeciwieństwie do architektury x86 gdzie mamy z powodu zachowywania na siłę zgodności z bardzo starymi wersjami procesorów niezły bałagan w rejestrach, których część jest jeszcze 16–bitowa, część, 32–bitowa i trochę 64–bitowa, a jeszcze trochę specjalnego przeznaczenia, ARM–64 ma 31, 64–bitowych rejestrów ogólnego przeznaczenia i kilka specjalnych (jak licznik programu i rejestr statusu w wersjach dla użytkownika i nadzorcy). Do tego dochodzą bardzo fajnie pomyślane instrukcje. Np. większość z nich zawiera kod uzależniający ich wykonanie od ustawień rejestru warunków. Czyli nie używa się dodatkowych instrukcji warunkowych. Inne cechy to instrukcje wykonujące dodawanie i operacje na bitach w jednym cyklu. Jak każdy współczesny procesor ARM ma też koprocesor arytmetyczny oraz „wektorową jednostkę multimedialną” NEON. W najnowszych wersjach ARM jest też wbudowane rozszerzenie TrustZone do operowania na wyjątkowo tajnych danych. Z tego mi. korzysta Touch ID.

Dla ciekawskich:
Rejestry w procesorach x86 Intela, Rejestry w procesorach ARM.

Znamienne jest to, że architektura x86 powstawała niewiele wcześniej (~1978 rok) od ARM (rozpoczęto prace w 1983 r.), a ARM już na starcie było znacznie bardziej nowoczesne. Pierwszy ARM2 był w pełni 32 bitowy z 26–bitową szyną adresową. Mógł zaadresować 64 MB pamięci czyli lepiej niż Motorola 68000, która mogła obsłużyć 16 MB. Miał też od razu aż 27, 32–bitowych rejestrów. Intele x86 w tym czasie posługiwały się stronicowym adresowaniem pamięci (koszmar), a trochę rejestrów 32–bitowych dostały w 1985 roku wraz z 80386.

Oczywiście poza samym procesorem w układach SoC Apple serii A znajdują się rdzenie procesora graficznego PowerVR (opracowywane przez firmę Imagination Technologies częściowo zależną od Apple, mającą jeden z oddziałów we Wrocławiu), dodatkowe jednostki wspierające jak MMU, a w wersjach dla iPhonów również pamięć RAM i inne „drobiazgi”.

A jak to jest w praktyce

Przeprowadziłem dla Was kilka testów porównawczych wydajności procesorów x86 i ARM. Ba! Nawet napisałem specjalny program do testowania prędkości, którego wersję na OS X już możecie pobrać z mojej strony (wersja na iOS czeka na akceptację u Apple). Program wykonuje serię prymitywnych obliczeń nie angażujących grafiki, jednostek wektorowych czy nawet specjalnie pamięci RAM. Testuje czystą prymitywną siłę procesora ;-)

Rywalizowały:
  • Apple MacBook Air mid 2013 procesorem i7 1,7 GHz oraz 8GB RAM
  • iPhone 6 plus z układem SoC A8 1,4 GHz i 1 GB RAM
  • iPhone 5s z układem SoC A7 1,3 GHz i 1 GB RAM (tylko test iMovie)
Wszystkie dwurdzeniowe i 64–bitowe.

Wyniki:

Mój: MacDevoteeBench dwa wątki:
  • iPhone 6 plus: 218 907 jednostek MacWyznawcy
  • MacBook Air: 2 066 049 jednostek MacWyznawcy
MacDevoteeBench jeden wątek:
  • iPhone 6 plus: 116 311 jednostek MacWyznawcy
  • MacBook Air: 983 307 jednostek MacWyznawcy
Wydawało by się, że dziewięciokrotna przewaga procesora Intela grzebie szanse na użycie ARM w komputerach w najbliższym czasie.

fdaa76c1-5f6f-4a07-acdf-e16851986ffe

Test wydajności przeglądarki Peacekeeper:

  • iPhone 6 plus: 2569
  • MacBook Air: 4511
Czyli w pierwszym praktycznym teście to już nawet nie jest dwukrotna przewaga mobilnego Intela „z najwyższej półki”!

83e28354-c2f2-44a2-94be-008062aaa8d4

Test iMovie:

  • iPhone 6 plus: 27 sekund
  • iPhone 5s: 31 sekund
  • MacBook Air: 52 sekundy
Ten test (podobnie jak przeprowadzony półtora roku temu) zakończył się dla Intela i7 pełną kompromitacją! A! I proszę mi nie marudzić, że to inne programy, inne ustawienia czy kodeki. Oba iMovie (dla iOS i OS X) wypuściły plik zakodowany w H.264 o rozdzielczości 1920x1080. Jedyna różnica jest taka, że plik z komputera ma dźwięk stereo, a z iPhona mono. Poprawka… źle sprawdziłem. Oba pliki mają dzwięk stereo.

4d7bc145-b8b4-4ff9-bc29-e874d1d6fd57
Przebieg testu zobaczycie na filmie: Test wydajności: Intel i7 kontra ARM Apple A8 i A7

Już niedługo (jak Apple dopuści mój „banchmark” dla iOS do App Store) wszystkie te testy będziecie mogli wykonać sami. Na razie udostępniam wam projekty dla iMovie oraz podaję adres testu przeglądarek.

Zachęcam do dzielenia się wynikami Waszych testów. Nie zapomnijcie też podać na jakim sprzęcie go dokonaliście.

Teraz wyobraźcie sobie, że Apple opracuje nowsze wersje układów A nie z 2 (lub 3 jak w przypadku A8X dla
iPad Air 2), a z 4, 6, 8 lub 12 rdzeniami. Do tego zastosuje zegar np. 2,5 GHz przy którym i tak będą one pobierać mniej energii niż mój i7. Taka moc pozwoli już na praktyczną emulację procesorów x86 nie gorzej niż Rosetta przy przesiadce z PowerPC na Intela! Zwłaszcza, że emulacja będzie dotyczyć tylko współcześnie używanych przez programy (i kompilatory) zestawów instrukcji i rejestrów x86 (i386, x86_64).

Czyli (moim zdaniem) w przyszłości architektura ARM może z powodzeniem zastąpić leciwą już architekturę x86. Jest szansa nawet i dla Intela ponieważ sam też przymierza się do produkcji procesorów na licencji ARM.

Kiedy możemy zobaczyć pierwsze komputery Apple z ARM w środku? Nie zdziwił bym się gdyby na tegorocznym WWDC Apple zapowiedział taki ruch i udostępnił narzędzia dla programistów. W takiej sytuacji komputery mogły by się pojawić już za rok. Mniej „optymistyczny” wariant to, zapowiedź na WWDC 2016 i pierwsze komputery w 2017 r.

A jak będzie czas pokaże… jednak czuję „w kościach”, że idą zmiany. Ostatni raz podobne „łamanie” odczuwałem na początku 2005 roku…






Wpis miał premierę na MacWyznawca.MyApple.pl