Po wstępie historycznym trochę przemyśleń co Apple, my (użytkownicy i programiści) możemy zyskać lub stracić przez hipotetyczne porzucenie architektury x86 na rzecz ARM oraz dlaczego tak może się stać.

Strona 1 z 3

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 ;-)

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.

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.

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.

alt text 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.

alt text 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.

O tym dlaczego takie nadzieje więżę z ARM dowiecie się na str. 2