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

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

ART - największa zmiana w Androidzie od czasu Androida [cz. 5]
Michał Mynarski
12.09.2014 18:34, aktualizacja: 12.09.2014 20:34

Jeżeli dotrwaliście do tego momentu to znaczy, że łyknęliście już naprawdę nieprzyzwoitą dawkę wiedzy teoretycznej. W ostatniej części, na podstawie testów wczesnej wersji ART, postaram się podsumować różnice między Dalvikiem i ART, a także zastanowić się nad zasadnością wprowadzenia nowego rozwiązania.

Ostatnia porcja teorii

Aplikacje, których wyniki zaraz ujrzycie, to programy stricte obliczeniowe. Najbardziej popularne z nich wykorzystują Android NDK. Co to jest?

Android Native Development Kit pozwala na używanie wstawek w języku programowania C lub C++. Są to języki niższego poziomu niż Java, które dużo łatwiej i wydajniej kompiluje się do kodu maszynowego. Jednak właśnie ze względu na ten fakt, użycie ART nie powinno wpłynąć szczególnie pozytywnie na wyniki w tych aplikacjach - część obliczeniowa benchmarków i na Dalviku była kompilowana bezpośrednio na procesor, a nie interpretowana jak Java. W testach AndroidPolice wyniki te nie powinny wykazać znaczącej poprawy w wydajności, co jest przeciwstawnym wnioskiem do powyższych danych z I/O.

Pomimo tych ograniczeń w czasie testów pojawiły się interesujące i nieoczekiwane rezultaty, które pomogły nam zrozumieć trochę bardziej obecny stan wydajności Androida.

Dlatego postarajcie się nie łączyć tego co poniżej zobaczycie z akapitami poświęconymi 64 bitom. Wyniki te to próbka możliwości pierwszej wersji ART, czyli udostępnionej do testowania na telefonach z 32-bitowymi procesorami. Dane naturalnie będą się różnić od tego, co Google pokazało na I/O ponad osiem miesięcy później.

Metodologia

Każdy benchmark był uruchamiany przynajmniej 4 razy na całkowicie gołym Nexusie 5 (bez roota). Po każdym z testów urządzenie było uruchamiane ponownie, a po starcie zostawiano je na 5 minut by załadowało wszystkie procesy początkowe. Do sześciu aplikacji typu benchmark, AndroidPolice dorzucił wyniki z dwóch testów przeglądarkowych - SunSpider i BrowserMark, które uruchomione były na Chrome. Warto na nie również rzucić okiem u źródła, tymczasem ja skupię się na samych benchmarkach.

Linpack, Real Pi Benchmark

Obie aplikacje testują wydajność czysto matematyczną - Linpack wyznacza potencjał naszego urządzenia w MFLOPS-ach. Real Pi - jak sama nazwa wskazuje - wyznacza liczbę Pi przy użyciu dwóch algorytmów. Co ważne ten pierwszy nie wykorzystuje NDK, tylko SDK, co jest humorystycznie wypunktowane w samej aplikacji, gdzie w opisie znajdziemy zdanie:

Ten test bardziej oddaje możliwości androidowej maszyny wirtualne Dalvik niż faktyczną wydajność obliczeń zmiennoprzecinkowych procesora.

Linpack uruchomiony na ART notuje ponad dziesięcioprocentowe zyski. Real Pi, jak wcześniej wspomniałem, składa się z dwóch testów. Pierwszy z nich jest wykonywany metodą AGM+FFT przy użyciu NDK - tutaj zyski są marginalne, ok 3.5%. Drugi wykorzystuje Javę dla metody Machina i wyniki otrzymujemy podobne do Linpacka - 11%.

Linpack, więcej = lepiej.
Linpack, więcej = lepiej.© własne, androidpolice.com
Real Pi, mniej = lepiej.
Real Pi, mniej = lepiej.© własne, androidpolice.com

Quadrant Standard, AnTuTu Benchmark

Pierwsze poważne zaskoczenie - pomiar CPU w QS dosłownie wysadza z butów notując niemal dwukrotnie lepszy wynik (95%). Poprawa ogólnego rezultatu tym samym to 42%.

Quadrant Standard, więcej = lepiej.
Quadrant Standard, więcej = lepiej.© własne, androidpolice.com

AnTuTu dla odmiany pokazuje całościowo marginalną stratę, jednak tutaj wszystkie "plusy" zniweczył test "UX Dalvik", który jak sama nazwa wskazuje, może promować właśnie ten sposób uruchamiania. Widzimy za to poprawę w obliczeniach zmiennoprzecinkowych na CPU oraz operacjach na pamięci RAM (lepsze wykorzystanie cache?), a także działaniach zapisu i odczytu, co może być spowodowane kilkoma specyficznymi optymalizacjami.

AnTuTu - szczegółowe wyniki, więcej = lepiej.
AnTuTu - szczegółowe wyniki, więcej = lepiej.© własne, androidpolice.com

CF-Bench i 3DMark

Pierwszy z nich wykonuje testy wykorzystując zarówno SDK, jak i NDK - tutaj bez zaskoczeń. Delikatna przewaga Dalvika zarysowuje się tam gdzie wchodzi kod natywny, co jest dość interesujące.

CF-Bench - punkt odniesienia Dalvik (0%).
CF-Bench - punkt odniesienia Dalvik (0%).© własne, androidpolice.com

Za to testy zaprzęgające Javę i SDK wykazują zauważalną poprawę przy przejściu na ART (poza pamięcią), potwierdzając to co widzieliśmy wcześniej (zmienny przecinek zyskuje najwięcej).

3DMark jest benchmarkiem wykorzystującym tylko NDK, spodziewano się więc wyników "na minusie" przy każdym teście... i takie też uzyskano. Chociaż zmiany nie są tak drastyczne i nie przekraczają 5%, to w żadnym z nich przejście na ART nie poprawiło osiągów.

3D Mark, punkt odniesienia - Dalvik (poziom 0%).
3D Mark, punkt odniesienia - Dalvik (poziom 0%).© własne, androidpolice.com

Warto jednak zapamiętać, że to są testy pierwszej wersji ART, jaką udostępniło Google. Od tego czasu wiele się zmieniło i drugie tyle zmieni się gdy L trafi do końcowych klientów.

Przeglądając komentarze natknąłem się również na opinie użytkowników, którzy na własną rękę testowali ART. Zwracali Oni uwagę na fakt, iż najbardziej tę zmianę odczują właściciele słabszych urządzeń, a nie flagowców.

fonix232:

Na moim Alcatelu OT-995 (Snapdragon S2, Adreno 205 - podzespoły bliźniaczo podobne do Galaxy S+) używam CyanogenMode 11.0 i różnica jest znacznie bardziej zauważalna. Na Dalviku urządzenie działało z opóźnieniami, nawet z optymalizacjami pod sprzęt o niskiej ilości pamięci RAM. Zmiana na ART - z miejsca wszystko zaczęło działać szybciej. Aplikacje otwierają się co najmniej dwukrotnie szybciej, zmiana pomiędzy nimi trwa błyskawicznie w porównaniu do gigantycznego laga jaki był przy Dalviku - innymi słowy, w rzeczy samej bardzo poprawiło to wydajność urządzenia

Przyszłość Androida nigdy nie prezentowała się w jaśniejszych barwach

Zbliżamy się do końca opowieści o ART, która w międzyczasie przerodziło się w historię o całym Androidzie jako systemie. Android RunTime to głośna manifestacja Google'a o treści: Nasz system jest pełnoletni

ART to szansa aby raz na zawsze rozprawić się z technicznie najbardziej uciążliwymi kwestiami Androida, a także fundament pod nowy lepszy system.

Jako deweloper nie mogłem prosić o więcej. Większość problemów wydajnościowych, które musiałem obchodzić "mądrym programowaniem" nie będą stanowić dłużej tak poważnego problemu. Oznacza to, że Android w końcu może konkurować z iOS w kwestiach płynności i wydajności, a największym wygranym w tym wszystkim jest przecież klient.

Android RunTime to nie tylko zwiększenie szybkości naszych urządzeń, ale również poprawienie ich responsywności, a w przyszłość może i skrócenie czasów reakcji na dotyk. Pozbycie się balastu zasobożernego Dalvika i przebudowanie Runtime'u od zera pozwoli na lepsze zarządzanie zasobami, co nie tylko uwolni potencjał podzespołów w smartfonach, ale również pozytywnie wpłynie na ilość wydzielanego przez nie ciepła oraz czas pracy na baterii.

To również ukłon w stronę twórców technologii, zarówno hardware'u jak i software'u. Google potwierdza, że Android jest gotowy na przyjęcie nowych rozwiązań (64 bity, nowe architektury; nie tylko ARM-owe) i nie będzie miał kompleksów w absorpcji już istniejących. Tym samym "zielony robocik" stanie się poligonem, gdzie technologie jutra mogą być wprowadzane, a największy bagaż z oznaczeniem "przeszłość" właśnie został porzucony. L i ART to krok z podniesioną głową w przyszłość - Google odrobiło lekcje i udowodniło, że słucha zarówno użytkowników, jak i deweloperów oraz producentów sprzętu. Dla nich i dla nas wszystkich nadchodzi nowe, lepsze. Warto zostać z Androidem - dziś bardziej, niż kiedykolwiek wcześniej.

Źródło artykułu:WP Komórkomania
Oceń jakość naszego artykułuTwoja opinia pozwala nam tworzyć lepsze treści.
Wybrane dla Ciebie
Komentarze (0)