ART - największa zmiana w Androidzie od czasu Androida [cz. 4]
W poprzednich trzech częściach starałem przybliżyć Wam to czym jest Dalvik i czym będzie ART, jak działa jeden i drugi i jakie miejsce zajmują w świecie technologii. W czwartej części tej publikacji zmierzymy się jeszcze z tematem 64 bitów oraz przytoczymy wyniki testów ich dotyczących.
Klucz do 64 bitów na Androidzie
Parę miesięcy temu w artykule o 64-bitowym układzie ARM, czyli Apple A7 w ostatnich akapitach pisałem tak:
Wraz z premierą 4.4 KitKat w systemie znalazło się nowe środowisko tzw. ART, które działa na innej zasadzie niż Dalvik (przepisuje aplikację na kod natywny albo bardzo do natywnego zbliżony). Intuicja i zdrowy rozsądek podpowiadają, że to ART będzie kluczowym elementem przy przejściu Androida na 64 bity i już pod to jest przygotowywany.
Jednej rzeczy nie byłem wtedy w stanie przewidzieć. Mianowicie, tego jak duże wsparcie uzyska Android wraz z wprowadzeniem ART. Podczas gdy iOS - prawdopodobnie - wprowadził obsługę 64-bitowych instrukcji tylko dla architektury ARM (co jest całkowicie zrozumiałe, gdyż ten system jest od początku do końca zaprojektowany pod te procesory), o tyle w przypadku zielonego robocika do grona wspieranych architektur dołącza desktopowe x86-64 oraz MIPS64 (aktualnie w posiadaniu Imagine Technologies, twórców grafik PowerVR).
O zaletach zastosowania 64 bitów pisałem już rok temu, kiedy to dosyć dokładnie opisywałem z czym się to wiąże i dlaczego ważne jest nie tylko ze względu na poszerzenie puli adresowanego RAM-u. Ważną różnicą między przejściem na A64 w wykonaniu Apple i Google jest wykorzystanie przez twórców Androida technologii reference compression, która pozwala uporać się z problematycznym rozrostem pamięci.
Wszystko rozbija się o wydajność - 64 bity zwiększają ilość kodu oraz długość wskaźników służących do adresacji pamięci (tak, to te same, które pozwalają na adresacje słynnych "więcej niż 4GB RAM-u"). Wskaźniki na komórki pamięci zawierające dane są teraz dwa razy dłuższe, a to w pewnych przypadkach może odbić się negatywnie na osiągach aplikacji w porównaniu do wersji 32-bitowej - np. poprzez zmniejszoną wydajność pamięci podręcznej (cache) i zwiększone wykorzystanie przepustowości pamięci CPU.
Reference Compression w sprytny sposób pozwala na wykorzystanie zalet 64 bitów, zachowując przy tym zyski płynące z "krótszej" adresacji. Technologia ta jest stosowana m.in. w 64-bitowej wersji maszyny wirtualnej Javy o nazwie JRockit JVM, która pozwala używać 32-bitowe wskaźniki (referencje) na pamięć. Taki zabieg nie tylko zwiększa wydajność, ale również optymalizuje wielkość sterty pamięci danej aplikacji.
Zyski i straty
Tyle teorii. Co z tego wszystkiego otrzyma przeciętny użytkownik Androida? Jak zaznaczałem kilkukrotnie do tej pory - przejście na ART może pomóc w rozwiązaniu kilku wymagających natychmiastowej poprawy kwestii, ale nie odbędzie się to oczywiście zerowym kosztem. Na początek rzućmy okiem na to, co samo Google zaprezentowało podczas ostatniego I/O.
Na załączonych grafikach możecie zobaczyć przegląd wyników benchmarków, który prezentuje wzrosty wydajności układów opartych na architekturach x86 (Intel) oraz ARM. Dotyczą one kolejno RenderScript (technologii w Androidzie obsługującej wymagające zadania obliczeniowe), Native (aplikacje korzystające z natywnych porcji kodu, o czym więcej napiszę później) oraz Crypto, czyli obliczeń kryptograficznych.
Na slajdach z I/O widzimy, że Renderscript na intelowskiej architekturze (po przejściu na 64 bity) notuje przyspieszenie od dwóch do ponad czterech razy zależnie od typu operacji. Native w wypadku ARM-owych rdzeni Cortex A57 i A53 zyskuje od ok. 12% do 20%, zaś obliczenia kryptograficzne wykonują się szybciej nawet do 15 razy. Oczywiście warto pamiętać, że to dane Google'a i za jakiś czas trzeba będzie je skonfrontować z niezależnymi testami. Niemniej jednak, nie można zaprzeczyć, że wzrost wydajności jest imponujący. Najciekawsze wnioski płyną z drugiej i trzeciej grafiki, ale aby je oceniać należy uzmysłowić sobie jak Google do nich "doszło".
Różnie między działaniem w 32 i 64 bitach na tych samych rdzeniach była możliwa do zaobserwowania dzięki podmianie ABI (ang. Application Binary Interface), które jest łącznikiem między plikiem wykonywalnym (odsyłam do części pierwszej tej publikacji) a procesorem. Uruchamiano więc benchmarki na tym samych rdzeniach (np. Cortex-A57) wykorzystując z ABI 32- i 64-bitowego. Wniosek z wykresów jest jeden - przejście na 64 bity ma dużo większy wpływ na wydajność w przypadku "oszczędnych" rdzeni Cortex-A53, niż tych dedykowanych bardziej wymagającym zadaniom (A57).
Google twierdzi, że 85% wszystkich aplikacji w Google Play jest gotowa do natychmiastowego przejścia na 64 bity co oznacza, że tylko 15% programów wykorzystuje w pewien sposób kod natywny i musi być rekompilowana pod 64 bitową architekturę. To wielkie zwycięstwo da Google i spodziewam się bardzo rychłego przejścia na 64 bity jak tylko producenci procesorów zaczną dostarczać takie SoC na rynek w nadchodzącym roku.
Za wnikliwe testy wziął się również serwis Android Police, który sporządził serię dokładnych, stricte obliczeniowo-wydajnościowych, doświadczeń w listopadzie zeszłego roku, więc niedługo po cichym wprowadzeniu ART wraz z Androidem 4.4 Kitkat. O tym jednak więcej już w ostatniej części.
Poprzednie możecie znaleźć tu: