Wiele osób porównuje przejście iPhone’a na 64 bity do historii komputerów PC. Większość użytkowników nie odczuła wyraźnej różnicy. Owszem, systemy operacyjne są lepiej zabezpieczone, potrafią adresować większą ilość pamięci operacyjnej a aplikacje które w znaczny sposób wykorzystują procesor komputera (edycja wideo, kompresja danych) pracują zauważalnie wydajniej. Komputery jednak “automagicznie” nie przyspieszyły.
64 bity to rozwój samego procesora
Warto jednak pamiętać, że mówimy tu o architekturze x86. A ta powstała z myślą o 16-bitowych procesorach. Została rozszerzona następnie, po latach, o 32 bity. W momencie, w którym nadciągnęła 64-bitowa rewolucja, x86 miał już niemal ćwierćwiecze bagażu historycznego za sobą. 64-bitowy skok był niezbędny do dalszego rozwoju. Warto też pamiętać, że architektura ARM, obecna w procesorach Apple’a, również ma już 25 lat historii za sobą.
A 64-bitowy Apple A7, czyli nowy procesor Apple’a, ma teraz dwukrotnie więcej rejestrów zmiennoprzecinkowych i ogólnego przeznaczenia od swojego poprzednika, dzięki czemu aplikacje nie muszą się tak często odwoływać do pamięci operacyjnej.
Na dodatek 64-bitowość iOS-a nie będzie tak technicznie problematyczna jak to ma miejsce w przypadku Windows. iOS 7 opiera się na modelu danych LP64. Dokładnie takim samym, jaki lata temu wprowadzono do OS X. Microsoft wybrał podejście LLP64, czyli tylko częściowe przejście na 64-bitową architekturę. Dzięki temu Windows dzierży w ręku wielką zaletę, jaką jest kompatybilność wsteczna z rozwiązaniami sprzed dekady. Apple nie musi się tym przejmować.
Deweloperzy są kluczowi
Rzecz jasna, by aplikacja mogła wykorzystać 64-bitowe dobrodziejstwa, musi być na nowo skompilowana. Tym jednak, na szczęście, w większości zajmuje się środowisko programistyczne Apple Xcode, odwalając za programistów większość “brudnej roboty”. Przy okazji, optymalizując aplikację pod iOS 7. Na dodatek 64-bitowa aplikacja uruchomi się na najnowszym iPhonie szybciej, bo ten nie będzie musiał ładować do pamięci 32-bitowych frameworków zapewniających wsteczną kompatybilność. Deweloperzy nie mają więc wymówek, by ignorować 64-bitowego iOS-a. A co z użytkownikami?
Przygotowane pod 64-bitowego iOS-a 7 aplikacje z całą pewnością nie będą działały dwukrotnie szybciej (w myśl logiki “2 x 32 = 64”). Będą mogły jednak wykorzystać dzięki temu większą ilość rejestrów procesora A7 i jego większą pamięć podręczną, nowe 64-bitowe zestawy instrukcji ARMv8. O nowych API w iOS 7 nawet nie wspominamy. Sama 64-bitowość może i faktycznie zmienia względnie niewiele dla mobilnych aplikacji. Ale związane z tym usprawniania procesora, które wykorzystane zostaną po skompilowaniu aplikacji pod nowego iOS-a z nową architekturą: jak najbardziej!
Istnieją jednak szanse, że ruch Apple’a to był duży błąd. Bardzo niewielkie, ale istnieją. Chodzi o owo przekompilowanie aplikacji pod nową architekturę. Aplikacje na iOS-a są chętnie aktualizowane i często aktualizowane. Nie było problemu przy zaprezentowaniu ekranów Retina, nie powinno więc być przy 64-bitowym Apple A7. Gdyby jednak się okazało, że deweloperzy będą mieli w nosie iPhone’a 5s (raz jeszcze: marne szanse), to ogólnie smartfon okaże się… wolniejszy. Za każdym razem bowiem system będzie obciążał pamięć dodatkowymi, 32-bitowymi bibliotekami, zmniejszając jej dostępność dla aplikacji i innych systemowych elementów.
Konkurencja włączy kserokopiarki?
Produkty i usługi firmy Apple można lubić lub nie, ale nie można im odmówić tego, że niejednokrotnie wskazywały kierunek rozwoju dla całego rynku. Android wręcz został przebudowany tuż przed swoją premierą, by móc nadgonić zaległości za iOS-em (wcześniej miał być alternatywą dla Windows Mobile i BlackBerry). Czy tym razem Google zdecyduje się na szybkie przejście na 64 bity?
Jest to mocno wątpliwe. Bo nie ma to, przynajmniej na razie, większego sensu. Przyczyną tego stanu rzeczy jest sama konstrukcja Androida. Jest to pełnoprawna dystrybucja linuksowa (a zatem, tak jak iOS, należy do uniksowej rodziny systemów operacyjnych), więc przepisanie go na 64 bity nie jest problemem.
Sęk w tym, że tak jak Android jest Linuxem, tak pisane dla niego aplikacje w większości nie są linuksowymi aplikacjami. Są to wykonywalne pliki pracujące pod przypominającą Javę maszyną wirtualną. Nie są to natywne aplikacje, tak jak na Cocoa Touch w iPhonie. W dużym uproszczeniu, niewiele się różnią od gierek flashowych czy javascriptowych na stronie internetowej. Oznacza to, że samo przejście Androida na 64 bity nie daje realnych korzyści. Należałoby również zoptymalizować środowisko Dalvik. A to będzie bardzo trudne.
Wirtualna maszyna Dalvik nie była zaprojektowana dla bardziej rozbudowanych aplikacji. Część deweloperów stara się to obejść, pisząc aplikacje (a zwłaszcza gry) wbrew zaleceniom Google’a w kodzie natywnym. Rozwiązanie to ma jednak wady z uwagi na dużą fragmentację w androidowym ekosystemie, zarówno jeżeli chodzi o sprzęt, jak i oprogramowanie. Aplikacja natywna napisana dla smartfonu Samsunga z Androidem Jelly Bean niekoniecznie zadziała na smartfonie HTC z Androidem Ice Cream Sandwich. Pod Dalvikiem, rzecz jasna, nie ma takich problemów. Dalvik to jednak wersja mobilnej Javy do uruchamiania prostych apletów, a nie wymagających aplikacji. Przepisanie Androida, Dalvika i aplikacji na 64 bity wymaga olbrzymiej ilości pracy. Na tyle dużej, że napisanie zupełnie nowego rozwiązania może się okazać mniej pracochłonne. Nie twierdzimy, że Google się tego nie podejmie. To jednak zajmie mu bardzo dużo czasu, a nie zapominajmy o wymaganym okresie przejściowym.
64 bity a sprawa Samsunga
Samsung już zapowiedział, że wkrótce jego układy również będą 64-bitowe. Co to jednak oznacza w myśl tego, co już przeczytaliśmy powyżej? Tu już możemy wyłącznie teoretyzować. Możliwe, że nie doceniamy Google’a i że prace nad 64-bitowym Androidem i środowiskiem dla aplikacji są bardzo zaawansowane. Możliwe też, że Samsung na własną rękę przekompiluje samego Androida na 64 bity, pozostawiając jednak 32-bitowy ekosystem aplikacji. Nie musimy dodawać, że wtedy owe 64 bity faktycznie będą miały głównie znaczenie marketingowe a wręcz będą przeszkadzać z uwagi na większe zapotrzebowanie na pamięć operacyjną (a tej Android potrzebuje więcej niż iOS).
Mamy jednak inną teorię. Przypominamy, że Samsung pracuje nad własnym systemem operacyjnym. Tizen to dystrybucja Linuxa, która ma połączyć wszystko co najlepsze z systemów bada, Moblin i Maemo. Tizen nie ma bagażu kompatybilności wstecznej i potężnego ekosystemu aplikacji.
Zapowiedź 64-bitowego procesora Samsunga może kryć w sobie zapowiedź dużo większej, agresywnej ofensywy. Wyobraźmy sobie 64-bitowego “Galaxy S 6” z 64-bitowym Tizenem i 64-bitowymi aplikacjami, a także uruchamianym na żądanie, 32-bitowym środowiskiem, pozwalającym na uruchamianie androidowych aplikacji z Samsung Apps. Biorąc pod uwagę fakt, że Samsung odpowiada za przytłaczającą większość zysków ze sprzedaży androidowych urządzeń, to nie tylko kontratak w kierunku Apple’a, ale również problem dla Google’a.
Niezależnie od tego, czy Android w końcu wejdzie w świat 64 bitów, czy też zrobi to Tizen, Apple znowu wszystkich wyprzedził. I może nie jest to tak wielka rewolucja, jak chce Tim Cook byśmy ją postrzegali, tak jest to kolejny, niezbędny krok w rozwoju mobilnych procesorów. I wszystko wskazuje na to, że konkurencja znowu będzie podążała za Apple, ponownie z co najmniej kilkunastomiesięcznym opóźnieniem.
