Nasi Czytelnicy nie ufają raczej benchmarkom czy innymsyntetycznym testom wydajności i energooszczędności, nauczenidoświadczeniem z firmami, które robiły co mogły, by ichurządzenia w testach wypadały jak najlepiej. To właśnie jeden ztakichtestów, przeprowadzony przez firmę ABI Research, pokazać miałodczuwalną wyższość Atoma Clover Trail+ Z2580 (m.in. w telefonieLenovo K900) nad takimi czipami w architekturze ARM jak QualcommSnapdragon czy Exynos Octa, przy zachowaniu zadowalającego poziomuzużycia energii przez układ Intela.
Możliwościom Atomów z uruchomionym na nich Androidem postanowiłprzyjrzeć się bliżej Rod Watt, inżynier konsorcjum ARM. Jakwiadomo, mobilny system operacyjny Google'a pozwala przede wszystkimna uruchamianie kodu pośredniego w maszynie wirtualnej Dalvik, aledopuszcza też uruchamianie kodu natywnego procesora (zazwyczajARMv7). O ile z uruchamianiem aplikacji napisanych w całości wkodzie pośrednim urządzenia z Intelem nie powinny mieć problemu,to w wypadku kodu natywnego w grę wchodzi jedynie jego translacja.
Na początku Watt postanowił więc przyjrzeć się, jakfaktycznie wygląda sytuacja z androidowym oprogramowaniem podwzględem rodzaju zastosowanego kodu. Pomogły mu listy top25płatnych i darmowych aplikacji i gier w sklepie Google Play. Jegoodkrycie zaskakuje: spośród sprawdzonych stu najpopularniejszychpozycji dla Androida, jedynie 20% działało wyłącznie na Dalviku.Cała reszta w mniejszym lub większym stopniu korzystała z kodunatywnego.
Jak twierdzi Intel, przeniesienie kodu ARMv7 na x86 niejest trudne, można by się więc spodziewać, że producencioprogramowania będą oferowali natywne komponenty swoich aplikacjitakże w postaci kodu dla x86. Tak jednak nie jest. Wśródsprawdzonych aplikacji, w lipcu 2013 roku jedynie 30% miało natywnąwersję x86. Pół roku później, w powtórzonym badaniu, ich liczbaspadła do 23%. Aby uruchomić na Atomie aplikacje wykorzystującekomponenty w kodzie ARMv7 (a takich w styczniu tego roku wśród stunajpopularniejszych było 44%), konieczne więc jest zastosowaniebinarnej translacji.
Binarny translator, opracowany we współpracy z Google, działanad warstwą kernela i bibliotek systemowych, a pod frameworkiemAndroida i bibliotekami Java Native Interface (opisującymi metodyinterakcji kodu pośredniego z pisanym w C/C++ kodem natywnym).Według Intela, translator działać miał w sposób niezauważalnydla końcowych użytkowników, z minimalnym narzutem w zużyciuenergii i mocy obliczeniowej. Aplikacje które znamy i kochamypo prostu miały działać.
Jak to zwykle bywa, slajdy swoje,a rzeczywistość swoje. Odsetek aplikacji z testowanego zbioru,który w ogóle nie uruchomił się na „atomowych” Androidachwyniósł 9%. Te zaś, które się uruchomiły w trybie binarnejtranslacji, działały odczuwalnie gorzej. W niektórych wypadkachich wydajność była wyraźnie gorsza. Jak wyraźnie? Watt sięgnąłpo benchmarki skompilowane w wersjach dla ARMv7 i x86, uruchamiającje na telefonie Lenovo K800, z procesorem Atom Z2460. Okazuje się,że różnice na niekorzyść binarnej translacji sięgały od 60 do80%. Towarzyszyły im wzrost obciążenia procesora i zwiększone onawet 90% zużycie energii.
Jeśli wyjść poza światAndroida, sytuacja też nie wygląda najciekawiej dla Atomów.Inżynier konsorcjum ARM porównał tablet Asusa T100 z procesoremAtom Z3740 (wykonanym w technologii 22 nm) i Windows 8.1 z tabletemNokii, działającym na procesorze Qualcomm Snapdragon 800 (wykonanymw technologii 28 nm) i Windows RT. Jak wyjaśnia, udało mu sięodizolować zasilanie dla układów SoC w obu urządzeniach. W teoriidziałający pod Windows czip Intela powinien sprawdzać sięznakomicie – Chipzilla ma całe dziesięciolecia doświadczeń zsystemami Microsoftu. A jednak nic z tego. Zarówno w testachsyntetycznych JavaScriptu, jak i funkcjonalnych (odtwarzanie wideo,aplikacje webowe etc.), SoC Intela okazywał się zużywać nawet o75% więcej energii, niż układ Qualcomma.
Wniosek jest prosty. Jeśliszukacie telefonu czy tabletu z Androidem i wasz wzrok padł nasprzęt z Atomem, sprawdźcie przede wszystkim, jak działać będąna nim ważne dla was aplikacje. Najwyraźniej bowiem programiściwciąż traktują Androida x86 po macoszemu – i z przedstawionychprzez Roda Watta danych wynika, że nie jest to wcale przejściowytrend. W przeciwnym wypadku kupicie urządzenie, które w realnejeksploatacji będzie bardzo odbiegało od tego, co zobaczyć można wdostosowanych do niego benchmarkach.
