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.

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.

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

Andrei Frumusanu:

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:

ART - największa zmiana w Androidzie od czasu Androida [cz. 1]

ART - największa zmiana w Androidzie od czasu Androida [cz. 2]

ART - największa zmiana w Androidzie od czasu Androida [cz. 3]