Jedną z najczęściej wymienianych różnic między ARM a x86 jest przydział do grupy architektur: CISC lub RISC. Te dwa skróty pochodzą sprzed kilkudziesięciu lat, kiedy projektowano pierwsze architektury komputerów przeznaczone do powszechnego użytku. Skrót RISC oznacza Reduced Instruction Set Computer, czyli komputer o zredukowanym zestawie instrukcji. Termin CISC ukuto, by przeciwstawić go temu pierwszemu: ma oznaczać komputer o złożonym zestawie instrukcji (Complex Instruction Set Computer). Architekturę ARM na ogół przydziela się do grupy RISC, a x86 – do CISC. Na czym polega różnica i czy jest ona dziś istotna?
Czym się różni RISC od CISC?
Próba intuicyjnego zrozumienia tych terminów sprowadzi na manowce. Znane są procesory CISC znające tylko osiem instrukcji oraz procesory RISC z setkami instrukcji. W rzeczywistości kategoryzacja jest inna: procesory RISC mają instrukcje przesuwające dane z pamięci do rejestrów oraz oddzielne instrukcje wykonujące operacje na rejestrach – ale nie ma instrukcji łączących pobranie danych z obliczeniem. W architekturach CISC jedna instrukcja może łączyć pobranie lub zapisanie danych z obliczeniami.
W czasach gdy powstawało to rozróżnienie, w jednym komputerze było niewiele poziomów pamięci i były one zbudowane z diametralnie różnych urządzeń. Pamięć operacyjna była znacznie wolniejsza niż rejestry procesora. W przypadku procesora RISC programista miał pewność, jak długo będą wykonywane poszczególne instrukcje, bo mogły one operować wyłącznie na rejestrach. Również instrukcje dostępu do pamięci zawsze trwały tyle samo. Procesor CISC z instrukcjami, które mogą operować albo na rejestrach, albo na pamięci operacyjnej, nie dawał takiej pewności: czasem instrukcja była wykonywana bardzo szybko, a czasem trzeba było czekać na dane z pamięci.
Gwarantowany stały czas wykonania instrukcji ułatwia projektowanie procesorów: łatwiej zapewnić stały ciągły przepływ instrukcji, bez przestojów w trakcie oczekiwania na dane. Ułatwia też pod pewnym względem programowanie i optymalizację kodu podczas kompilacji.
Z czasem procesory znacznie się skomplikowały i różnice w adresowaniu straciły na znaczeniu. Pamięć operacyjna coraz wyraźniej nie nadążała za coraz wydajniejszymi procesorami, a programy stawały się coraz bardziej skomplikowane. Instrukcje wykonywane szybko i w przewidywalnym czasie przestały być receptą na zapełnienie jednostek wykonawczych procesora pracą. CPU stały się bardzo szerokie – mogą jednocześnie wykonywać kilka instrukcji różnego typu. Mogą też wykonywać instrukcje poza kolejnością, co znaczy, że kod programu jest obserwowany i analizowany z dużym wyprzedzeniem w stosunku do właśnie wykonywanej instrukcji.
Po drugie, podsystem pamięci zamiast jednego poziomu ma ich wiele. Kilka poziomów pamięci podręcznej, z których każdy kolejny jest pojemniejszy i wolniejszy od poprzedniego, ma zadanie zminimalizować czas oczekiwania na dostęp do RAM-u. Dane z pamięci prawie nigdy nie są pobierane dopiero przy próbie wykonania instrukcji, która ich potrzebuje – zaawansowane algorytmy pobrania z wyprzedzeniem załatwiają to znacznie wcześniej.
...W nowoczesnym procesorze – prawie niczym
W ten sposób jedna z podstawowych różnic między RISC a CISC straciła praktyczne znaczenie. Nieważne, czy jedna instrukcja pobiera dane z pamięci i coś z nimi robi, czy pobranie jest rozdzielone od obliczenia. Front-end procesora i tak już dawno sprawdził adresy występujące w kodzie, dane zostały pobrane z wyprzedzeniem do któregoś poziomu szybkiej pamięci podręcznej, a same instrukcje – podzielone na mikrooperacje i poprzestawiane tak, żeby nie było zbyt dużych przestojów w pracy jednostek wykonawczych.
Zasadnicze różnice między RISC i CISC miały znaczenie w przeszłości i mogą je mieć dzisiaj w skrajnie prostych i niewielkich procesorach. W zaawansowanych CPU podsystem pamięci, nowoczesne techniki wykonywania instrukcji poza kolejnością i rozdzielanie ich na mikrooperacje oraz kompilator ukrywają te różnice.
Czy architektura ARM jest bardziej energooszczędna?
Architektury ARM i MIPS często są uważane za z natury bardziej energooszczędne od x86. Znając najważniejsze dziś ograniczenia w cyfrowych obliczeniach, trudno uzasadnić, dlaczego miałoby tak być. Czas wykonania programu i zużyta do tego energia są ostatecznie ograniczone prędkością pamięci, stopniem skomplikowania procesora i tym, jak bardzo da się zrównoleglić kod. Jeśli każdy procesor wykonuje ten sam program, korzysta z takich samych rodzajów pamięci i jest w podobnym stopniu zaawansowany technicznie, to co może się różnić?
Jak pokazują współczesne badania, w procesorach o dzisiejszym stopniu skomplikowania sama architektura nie ma widocznego wpływu na efektywność energetyczną. To nie znaczy, że nigdy i nigdzie nie miała wpływu: w bardzo małych procesorach, w których budżet energetyczny i budżet tranzystorów są bardzo ograniczone, architektura wciąż ma znaczenie.
Przeciętny procesor ARM jest bardziej energooszczędny od przeciętnego procesora x86 – ale nie jest to zasługą jego architektury. Architektura ARM zaczęła swój rozwój od wspomnianych małych i energooszczędnych procesorów i w ostatniej dekadzie zmierza ku większym i wydajniejszym. Procesory x86 przez długie lata miały być tylko wydajne, efektywność energetyczna i całkowita energooszczędność dopiero w ostatniej dekadzie zaczęły być istotne. ARM rozwija się „wzwyż”, a x86 – „w dół”; procesory ARM stają się coraz większe i wydajniejsze, co jest konieczne do wykorzystania ich w wysokowydajnych smartfonach, komputerach przenośnych i serwerach.
Wydajność procesora, maksymalna częstotliwość taktowania, liczba tranzystorów, zajmowana powierzchnia i zużywana energia zależą głównie od techniki produkcji oraz decyzji projektowych podjętych przez konstruktorów. Rdzenie Airmont w Xeonie Phi mają tę samą architekturę x86 co rdzenie Skylake w procesorach Core i7, wykonają nawet ten sam program bez rekompilacji, ale nie mają z nimi o wiele więcej wspólnego. Te pierwsze osiągają taktowanie do 1,5 GHz, mają czterodrożną symultaniczną wielowątkowość (SMT) i ograniczone możliwości wykonywania instrukcji poza kolejnością. Drugie występują w wersjach taktowanych z częstotliwością od 1,2 GHz do 4 GHz, mają dwudrożną wielowątkowość i najbardziej zaawansowane możliwości wykonywania kodu out-of-order spośród wszystkich procesorów. Podobne różnice znajdziemy w procesorach ARM – najmniejsze, takie jak Cortex-M0, nie mają nawet tak bogatego zestawu instrukcji jak rdzenie Apple, Qualcomma czy Cortex-A57.
ARM kontra x86 a liczba tranzystorów
Jak wspomnieliśmy, architektura jak najbardziej ma znaczenie, kiedy projektanci procesora mają do dyspozycji mocno ograniczoną liczbę tranzystorów. Tak zwany „podatek x86”, czyli liczba tranzystorów, jaką trzeba poświęcić na stosunkowo skomplikowany dekoder instrukcji x86, jest tym bardziej dotkliwy, im mniej tranzystorów mamy do dyspozycji. Podczas pierwszych zapowiedzi procesora AMD K12 jego projektant, Jim Keller, powiedział, że wykorzystanie architektury ARM pozwala mu przeznaczyć więcej tranzystorów na funkcje zwiększające wydajność. To dość ogólne stwierdzenie, o którego prawdziwości mogą być przekonani dzisiaj tylko projektanci K12 (i tylko dla nich ma ono znaczenie).
Koszt tranzystorów stale maleje wraz z postępem w litografii i nawet w najbardziej ograniczonych budżetem energetycznym procesorach będzie można sobie pozwolić na „podatek x86”. Na razie płaci go tylko Intel w swoich układach Quark, bez większego skutku: o komercyjnych zastosowaniach Quark niezwiązanych z budżetem marketingowym Intela nic nie wiadomo.
Co jest łatwiejsze w programowaniu?
Ze względu na skomplikowanie kodu dzisiejszych programów użytkowych mikrooptymalizacją zajmują się wyłącznie kompilatory. Programiści pracują w językach wysokopoziomowych i korzystają z przygotowanych wcześniej bibliotek standardowych. Oczywiście, staranna optymalizacja kodu ciągle jest możliwa i konieczna, ale programiści po prostu podążają za ogólnymi wytycznymi, a twórcy kompilatorów dbają o to, żeby w zależności od architektury procesora dały one jak najlepszy efekt. O łatwości programowania decyduje ostatecznie dostępność i jakość narzędzi programistycznych, a nie architektura procesora.
Jedna z najważniejszych różnic między procesorami x86 a procesorami ARM dotyczy nie ich architektury, a licencji na nie i tego, jak są przekuwane na gotowe produkty. W środowisku pecetowym jesteśmy przyzwyczajeni do modelów biznesowych Intela i AMD. Ogólnie pojęta licencja x86 (czyli licencja na tworzenie procesorów zgodnych z tym zestawem instrukcji) to współczesna wersja węzła gordyjskiego – poplątanych zależności między Intelem, AMD i VIA – do którego mają dostęp jedynie te trzy firmy. Intel ma pełną kontrolę nad swoimi procesorami, bo nie tylko je projektuje, ale też produkuje w swoich fabrykach, po czym dystrybuuje do klientów. AMD i Nvidia nie mają własnych fabryk, więc produkcję zaprojektowanych przez siebie czipów zlecają zewnętrznym firmom (TSMC, GlobalFoundries), a zarazem ściśle współpracują z nimi w czasie przygotowywania linii produkcyjnych.
W przypadku ARM wygląda to zupełnie inaczej. Firma ta nie oferuje gotowych procesorów ani też nikomu nie zleca ich wytworzenia (poza pewnymi wyjątkowymi sytuacjami, o których za chwilę), a w swoim katalogu umieszcza jedynie różnego rodzaju licencje, które może kupić każdy producent posiadający odpowiednią ilość gotówki.
Najmniej ciekawa (przynajmniej z punktu widzenia miłośników technicznych nowinek) jest licencja POP (Processor Optimization Pack). Firmy decydujące się na nią przeważnie nie mają możliwości (albo chęci) samodzielnej implementacji rdzeni ARM lub projektowania ich od zera. Licencja POP obejmuje wybrane, konkretne rdzenie ARM (w tej chwili dostępne są: Cortex-A72, Cortex-A53, Cortex-A35, Cortex-A9, Cortex-A7, Cortex-A5 i Cortex-M) w wybranej konfiguracji (od jednego do czterech), układ graficzny Mali-T880/T860, zestaw interkonektów oraz instrukcje, jak to wszystko ze sobą poskładać i wyprodukować w konkretnym procesie technologicznym, oferowanym przez jedną z wybranych fabryk. Inaczej mówiąc, nabywca licencji POP otrzymuje niemalże kompletny schemat procesora w wybranej przez siebie konfiguracji, którego produkcję może względnie szybko i bezboleśnie rozpocząć u danego wykonawcy. Z drugiej strony jest ona mało elastyczna, nie pozostawia pola na własne optymalizacje i ktoś, kto z niej korzysta, zawsze jest trochę w tyle za firmami opracowującymi wszystko we własnym zakresie.
Bardziej zaawansowanym rodzajem licencji jest licencja na konkretną architekturę rdzenia zaprojektowanego przez ARM (Cortex-A73, Cortex-A72, Cortex-A57 i tak dalej), którą trzeba samemu fizycznie zaimplementować w tworzonym przez siebie procesorze, z myślą o wybranym procesie technologicznym. ARM dorzuca do tego licencję na interkonekty i umożliwia dokupienie licencji na wybrany układ graficzny, więc od firmy tej można kupić niemal wszystkie niezbędne elementy SoC-a. Nie oznacza to jednak, że ich nabywca ma łatwe życie, bo połączenie tego wszystkiego w sensowny sposób i przystosowanie do konkretnego procesu wcale nie jest łatwe i wymaga dużej wiedzy i sporego nakładu pracy. Właśnie z tego rodzaju licencji korzystają inżynierowie HiSilicon, gdy projektują Kiriny, inżynierowie Samsunga, gdy tworzą większość Exynosów, czy pracownicy Qualcomma, gdy uznają, że z jakiegoś powodu nie opłaca się projektować czegoś od zera (przykładem Snapdragony serii 200, 400, 600 i osławione Snapdragony 808 i 810).
Trzecim z głównych rodzajów licencji jest licencja na tworzenie własnych procesorów zgodnych z wybranym zestawem instrukcji ARM (32-bitowy ARMv7 lub starszy, 64-bitowy ARMv8). Korzystają z niej tylko najbardziej ambitne firmy, które potrafią zaprojektować procesor od zera i uważają, że w ich przypadku będzie to miało więcej sensu niż skorzystanie z gotowych rozwiązań ARM. W sumie, choć ARM ma ponad 300 klientów, tylko kilkunastu z nich zdecydowało się na ten rodzaj licencji, co raczej nikogo nie dziwi, bo uzdolnieni architekci procesorów są kosztowni i ich populacja jest porównywalna z populacją białych nosorożców...
Od niedawna ARM oferuje nowy rodzaj licencji, który można umieścić gdzieś pomiędzy drugą a trzecią z wymienionych. Nabywca licencji Built on ARM Cortex Technology bierze jeden z gotowych rdzeni i może poprosić ARM o zmodyfikowanie go, żeby lepiej utrafił w konkretne potrzeby. Co ciekawe, powstały w ten sposób rdzeń może mieć nazwę zupełnie niezwiązaną z Corteksem, na którego fundamencie zostanie zbudowany, więc za jakiś czas możemy mieć problem z rozpoznaniem, czy jakiś procesor został faktycznie zaprojektowany przez kogoś od zera, czy jest to Cortex przeprojektowany głównie przez architektów ARM. Pierwszym nabywcą tej licencji jest Qualcomm, ale na razie trudno przewidzieć, jaki będzie miała ona wpływ na kształt przyszłych Snapdragonów.
Najważniejsze implementacje architektury ARMv8-A
Stworzone przez ARM
Firma ARM oferuje wiele różnych projektów rdzeni CPU, podzielonych na dwie główne rodziny. Cała gama rdzeni jest potrzebna do zrealizowania czegoś w rodzaju metaarchitektury ARM, czyli sposobu, w jaki CPU ARM są wykorzystywane w układach system-on-a-chip (SoC).
Propozycja makroarchitektury ARM polega na przetwarzaniu heterogenicznym, czyli użyciu kilku różnych maszyn obliczeniowych w ramach jednego systemu i przypisywaniu zadań do tej maszyny, która najlepiej sobie z nimi poradzi. Co jest najlepsze – o tym decyduje projektant. Czasem najlepsza jest wydajność (np. w superkomputerach złożonych z GPU i CPU), ale w urządzeniach przenośnych – które są głównymi odbiorcami zaawansowanych rdzeni ARM – najważniejsza jest efektywność energetyczna, czyli złoty środek między wydajnością a energooszczędnością. Technika przetwarzania heterogenicznego ARM nazywa się big.LITTLE i polega na zastosowaniu w jednym SoC kilku niewielkich, niskoenergetycznych rdzeni oraz kilku rozbudowanych, wysokowydajnych, i przełączaniu się między nimi w zależności od zadań wykonywanych przez urządzenie.
W stanie spoczynku mają pracować lekkie rdzenie, które doskonale radzą sobie z zadaniami wykonywanymi w tle, kiedy użytkownik nie wymaga szybkiej reakcji urządzenia. Duże rdzenie mają być wykorzystywane do bardziej wymagających zadań, kiedy użytkownik nie chce czekać albo kiedy nie można marnować energii na podtrzymywanie pracy innych części urządzenia (np. ekranu, modemów radiowych) przez cały czas potrzebny powolnym rdzeniom na skończenie obliczeń.
Wspomniane dwie rodziny rdzeni ARM można (z małymi wyjątkami) podzielić na te, które w konfiguracjach big.LITTLE mają występować w charakterze części big, i te, które mają występować jako części LITTLE. Jako LITTLE wykorzystuje się rdzenie o uproszczonym front-endzie, które nie mogą wykorzystywać instrukcji poza kolejnością. Należą do nich:
- Cortex-A32 – najmniejszy rdzeń w obecnie wykorzystywanej architekturze ARMv8-A, wyłącznie 32-bitowy
- Cortex-A35 – najmniejszy 64-bitowy rdzeń ARM
- Cortex-A53 – najbardziej rozbudowany rdzeń ARM in-order; polecany przez ARM jako następca popularnego Corteksa-A7 i A9. Obecnie najpopularniejszy po Corteksie-A9 rdzeń ARM.
Wszystkie wymienione rdzenie mają stosunkowo krótki potok wykonawczy (do ośmiu etapów) i są dwudrożnie superskalarne, czyli mogą wykonywać maksymalnie dwie instrukcje jednocześnie. Cortex-A32 jest przeznaczony do zastosowań wbudowanych, do wykorzystania jako główny procesor. Teoretycznie mógłby być stosowany w konfiguracji big.LITTLE, ale tylko w połączeniu z innym 32-bitowym procesorem ARMv8-A – a wszystkie inne są 64-bitowe.
Do bardziej wymagających zadań wykorzystuje się – również jako rdzenie big w wielordzeniowych SoC – rdzenie z rodziny wysokowydajnych procesorów out-of-order. Ich rozbudowany front-end, wymagany do wykonywania instrukcji poza kolejnością, wydłuża potok wykonawczy, zużywa znaczną część budżetu energetycznego procesora i zajmuje sporą powierzchnię, ale zapewnia wysoką wydajność w wykonywaniu jednowątkowego kodu. Należą do nich:
- Cortex-A57 – podstawowy wysokowydajny rdzeń ARMv8-A. Stał się podstawą pierwszych 64-bitowych SoC dla wielu producentów.
- Cortex-A72 – najwydajniejszy uniwersalny rdzeń ARMv8-A. Ewolucyjne ulepszenie A57. Jest od niego wydajniejszy zegar-w-zegar o kilkanaście procent. Dzięki optymalizacjom layoutu ma być lepiej przystosowany do działania przez dłuższy czas z najszybszym taktowaniem niż Cortex-A57.
- Cortex-A73 – najnowszy projekt ARM, jeszcze niedostępny w żadnym SoC. Usprawniony energetycznie względem A57 i A72. Dzięki rozbudowanemu front-endowi ma krótszy potok wykonawczy niż A57 i A72 (10 zamiast 14 etapów). Porzucono w nim niektóre funkcje makroarchitekturalne konieczne do zintegrowania układu w specjalistycznych przemysłowych SoC.
Poza architekturą samych rdzeni CPU firma ARM oferuje inne składniki układów SoC: sposoby połączenia rdzeni w kilkurdzeniowe grupy ze wspólną pamięcią podręczną oraz magistrale zachowujące spójność pamięci i umożliwiające połączenie rdzeni ARM z różnymi koprocesorami. Niektóre z nich są w pewnym stopniu wbudowane w rdzeń ARM i są konieczne do budowy SoC do specyficznych zastosowań. Na przykład Cortex-A73 jest zoptymalizowany do wykorzystania w smartfonach i tabletach; nie ma magistrali AMBA5, koniecznej do budowy serwerowego SoC z więcej niż czterema rdzeniami albo z przestrzenią adresową pamięci wspólną dla rdzeni ARM i jakichś dodatkowych koprocesorów.
Stworzone przez licencjobiorców ARM
Szczegóły różnych mikroarchitektur ARM nie są tak chętnie ujawniane jak w przypadku nowych procesorów x86. Nie wiemy o nich nawet tyle co o rdzeniach Cortex przygotowywanych przez firmę ARM. Apple, Qualcomm czy Samsung nie ujawniają nawet takich danych jak pojemność pamięci podręcznej. Większość informacji o tych rdzeniach pochodzi z niezależnych analiz mikroskopowych i starannie dobieranych benchmarków syntetycznych. Wymienimy najważniejsze własne implementacje 64-bitowej architektury ARMv8.
- Apple Twister – własny rdzeń Apple wykorzystywany w procesorach A9 i A9X. Następca mikroarchitektur Cyclone i Typhoon. Jeden z najszerszych rdzeni ARM (może wydawać sześć instrukcji jednocześnie) i jeden z najbardziej ukierunkowanych na wydajność pojedynczego rdzenia, co pozwala Apple stosować konfiguracje dwurdzeniowe zamiast co najmniej czterordzeniowych, jak u innych producentów.
- Qualcomm Kryo – rdzeń używany m.in. w układzie Snapdragon 820, w obydwu rolach konfiguracji big.LITTLE: rdzenie big mają więcej pamięci podręcznej i szybsze taktowanie.
- Samsung M1 – cztery takie rdzenie są wykorzystywane w układzie SoC Exynos 8 Octa 8890 w połączeniu z czterema Cortex-A53 w konfiguracji big.LITTLE. Rdzenie M1 są w tym czipie taktowane z częstotliwością do 2,6 GHz.
- Nvidia Denver – procesor VLIW wykorzystujący tłumaczenie instrukcji ARM na wewnętrzny zestaw instrukcji (więcej informacji można znaleźć w artykule „Rozważania na temat ograniczeń technicznych i patentowych dotyczących architektury x86”). Wykorzystywany w dwurdzeniowej wersji układu Tegra K1, jest taktowany z częstotliwością do 2,5 GHz. Dwa rdzenie Denver drugiej generacji mają być wykorzystane w konsoli Nintendo NX obok czterech rdzeni Cortex-A57.
- Cavium ThunderX – procesor serwerowy, pochodna architektury Octeon, stosowanej w układach zarządzających sieciami. Ma wydajność zbliżoną do osiągów Cortex-A57, ale krótki potok wykonawczy powoduje, że jest lepiej dostosowany do wykonywania kodu z dużą liczbą nieprzewidywalnych rozgałęzień.
- Applied Micro X-Gene – procesor serwerowy, zaprojektowany głównie do zastosowań sieciowych. Obecnie dostępna druga generacja ma osiem rdzeni taktowanych z częstotliwością 2,4 GHz i jest produkowana w procesie technologicznym 40 nm. W przyszłym roku ma być dostępna trzecia generacja SoC w architekturze X-Gene, wyposażona w 32 rdzenie i wielokanałowy kontroler DDR4.
Nadchodzące
Wymienione poniżej procesory ARM są w fazie projektowania i od dłuższego czasu nie ma o nich żadnych nowych informacji.
- AMD K12 – wysokowydajny procesor z czterodrożną wielowątkowością (SMT). Pierwsze prototypy były gotowe na początku tego roku; ma trafić do serwerów w 2017 roku.
- Broadcom Vulcan – serwerowy procesor Broadcoma, również z czterodrożnym SMT. Ma być produkowany w procesie technologicznym 16 nm FinFET i osiągać taktowanie do 3 GHz. Jako jeden z pierwszych będzie wykorzystywał odświeżoną architekturę ARMv8.1-A.
Problemy z oceną wydajności procesorów ARM
Na dalszych stronach analizujemy wydajność różnych procesorów ARM, a potem próbujemy odnieść wyniki do tego, co znamy ze świata x86. Najpierw musimy jeszcze wyjaśnić kilka rzeczy i omówić pewne problemy, które przysparzają tego rodzaju porównania.
1. Ten sam procesor w różnych urządzeniach może zapewniać zupełnie inną wydajność
Rynek mikroserwerów ARM jeszcze raczkuje, więc docelowym sprzętem dla wysokowydajnych układów ARM są w tej chwili różnego rodzaju urządzenia przenośne: smartfony, tablety i chromebooki. I to właśnie głównie smartfony posłużyły nam w tym teście za swoiste platformy testowe procesorów. Jedynym użytym przez nas niesmartfonem jest konsola Nvidia Shield TV z aktywnie chłodzoną Tegrą X1.
Niestety, najwydajniejsze czipy ARM często są... trochę zbyt wydajne. Zbyt wydajne w tym sensie, że urządzenia rozmiarów smartfona nie są w stanie efektywnie odprowadzić produkowanego przez nie ciepła. O ile większość telefonów osiąga maksymalną wydajność w czasie krótkich testów syntetycznych pokroju Geekbencha i AnTuTu, o tyle wszystkie dłuższe benchmarki są dla nich bardzo problematyczne. A niektóre z wykorzystanych przez nas testów mogą trwać nawet kilkanaście minut. W szczególnych przypadkach prowadzi to do takiej oto sytuacji:
Ta sama jednostka centralna, a wyniki zupełnie inne. Jak widać, nazwa i „pudełkowe” taktowanie jakiegoś procesora w praktyce mogą nam niewiele mówić o tym, jaką wydajność dostaniemy. Oczywiście, osławiony Snapdragon 810 to skrajny przypadek i jego problemy z apetytem na prąd są wręcz legendarne, ale i tak w tej chwili na rynku nie ma telefonów z procesorem wysokiej klasy, które w ogóle nie spowalniają taktowania w czasie, gdy obciążone są wszystkie rdzenie. Przygotowując ten tekst, sprawdziliśmy, jak to dokładnie wygląda w przypadku kilku znanych smartfonów z różnymi czipami. Zbadaliśmy, jak kształtuje się ich taktowanie, gdy na dłużej obciąży się wszystkie rdzenie procesora, cztery z nich lub tylko dwa. Poniższe wykresy przedstawiają częstotliwość taktowania jednostki centralnej w czasie kodowania wideo za pomocą biblioteki x264 uruchomionej z flagą ograniczającą maksymalną liczbę wątków.
Skalę problemu najlepiej widać po Samsungu Galaxy S6. Jego Exynos 7420 utrzymuje swoje maksymalne taktowanie tylko przez pierwszych kilka sekund trwania testu – i to nawet wtedy, gdy wykorzystuje się tylko dwa z jego rdzeni. Na podstawie tego rodzaju wyników nie można jednoznacznie i ostatecznie ocenić wydajności omawianego procesora i trzeba mieć to w pamięci w czasie analizowania wykresów na dalszych stronach. Sytuacja wygląda znacznie lepiej w przypadku testów jednowątkowych; one w miarę dobrze reprezentują potencjał konkretnej architektury.
2. Wszystkie dalsze porównania mają charakter orientacyjny
...w mniejszym lub większym stopniu. Po pierwsze, z powodu opisanego powyżej, a po drugie dlatego, że nie mamy pełnej kontroli nad wszystkim, co wpływa na wydajność w danym teście. Smartfonowe procesory są łączone z pamięcią operacyjną (RAM) o różnej szybkości i z oczywistych powodów nie można wymienić jej na inną. Układy te różnią się też taktowaniem, więc trudno o w pełni satysfakcjonujące porównanie „zegar w zegar”. Teoretycznie dałoby się przejąć nad tym kontrolę po zrootowaniu systemu i ustawieniu własnych tablic częstotliwości taktowania; niestety, nie możemy robić takich rzeczy z telefonami, które dostajemy do testów.
Jeszcze o jednym trzeba szczególnie pamiętać w czasie lektury wszelkich porównań wydajności układów ARM-ów z procesorami x86: testy te są uruchamiane w urządzeniach z zupełnie różnymi systemami operacyjnymi. Trzonem naszej analizy są własnoręcznie skompilowane pod Windows i Androida wersje 7-Zipa, x264 oraz Lame MP3 i pilnujemy, żeby w każdym przypadku kompilator ustawiał takie same optymalizacje. Niestety, różne platformy to różne platformy. Krótko mówiąc, wyniki naszych testów nie mają powiedzieć, o ile procent procesor X jest szybszy od procesora Y, a jedynie pokazać przybliżoną skalę różnic między nimi.
3. Wielcy nieobecni
Wielu z Was zapewne zauważy, że w naszych porównaniach na większości wykresów brakuje sprzętu Apple. Niestety, urządzenia tej marki po prostu nie pozwalają uruchomić wszystkich potrzebnych narzędzi.
Porównanie wydajności procesorów ARM
Czas na najważniejsze, czyli benchmarki. Wyniki podzieliliśmy na dwie grupy: w pierwszej zebraliśmy testy jednowątkowe, a w drugiej – wielowątkowe. Posłużyliśmy się popularnym Geekbenchem i testami procesora w 3DMarku, ponieważ są to narzędzia multiplatformowe, dostępne w wersjach na Androida, iOS i PC. Do tego dorzuciliśmy swoje testy rzeczywiste: kodowanie wideo x264, kompresowanie dużego pliku 7-Zipem i kompresję audio z formatu WAV do MP3. Powstawanie i sposób działania tych testów opisywaliśmy na blogu PCLab.pl, ale na potrzeby tego artykułu zostały zaktualizowane: korzystamy z wersji x264 z początku czerwca, FFmpega zaktualizowaliśmy do wersji 3.0 (najnowszej dostępnej w momencie rozpoczęcia testów), a 7-Zip w końcu jest 64-bitowy. To samo się tyczy windowsowych wersji tych testów: FFmpeg, LAME, x264 i 7-Zip skompilowaliśmy samodzielnie przy użyciu tego samego kompilatora (GCC 4.9, bo nowsze wersje nie są obsługiwane przez Android NDK, a Clang stwarzał nam problemy) i tych samych ustawień, co w przypadku androidowych wersji tych narzędzi.
Wniosek 1.
Rdzenie Apple są bardzo szybkie – wygląda na to, że najszybsze „zegar w zegar” spośród istniejących rdzeni ARM. Co prawda mamy trochę zbyt mało ich testów, żeby stwierdzić to definitywnie, a w testach wielowątkowych muszą one uznać wyższość jednostek ośmiordzeniowych, ale bardzo chcielibyśmy móc kiedyś dokładniej porównać ich wydajność z osiągami mobilnych rozwiązań Intela, bo czujemy, że byłoby ciekawie.
Wniosek 2.
W tej chwili architektura Qualcomma rządzi w świecie Androida. Rdzenie Kryo są bardzo szybkie i Snapdragon 820 nawet pomimo wolniejszego taktowania wyprzedza w większości testów jednowątkowych procesory oparte na dużych rdzeniach Cortex-A72 i Samsung M1. Jeśli jednak Cortex-A73 będzie tak szybki i tak efektywny energetycznie, jak to obiecuje ARM, końcówka roku znowu powinna należeć do tej firmy.
Wniosek 3.
Choć Qualcomm rządzi w testach jednowątkowych, to w wielowątkowych musi uznać wyższość szybciej taktowanej, ośmiordzeniowej konkurencji. Lepiej mieć więcej wolniejszych czy mniej szybszych rdzeni? Apple i Qualcomm uważają, że w smartfonach i tabletach lepsze jest to drugie, i my – pomimo mało przychylnych wyników benchmarków – jesteśmy podobnego zdania.
Wniosek 4.
To przerażające, jak słabe są rdzenie Cortex-A53. „Zegar w zegar” są one mniej więcej dwa razy wolniejsze od najmocniejszych rdzeni ARM. To oznacza, że między smartfonami najwyższej klasy a tymi ze średniej półki powstała wydajnościowa przepaść, którą naprawdę czuć w trakcie bardziej intensywnego użytkowania sprzętu i której nie da się zasypać przez dorzucanie kolejnych rdzeni. Dlatego tak ważnym układem jest Snapdragon 650 i mamy nadzieję, że szybko zdobędzie popularność, a Huawei i Mediatek dodadzą do swojej oferty jego odpowiedniki.
Wniosek 5.
To przerażające, jak słabo wypada w tych wszystkich testach Snapdragon 805. Jest to ostatni czołowy procesor 32-bitowej ery i swego czasu naprawdę zachwycał wydajnością, a obecnie – szczególnie w kontekście bardzo szybkiego taktowania (nadal jest to najszybciej taktowany smartfonowy procesor w historii) – wywołuje ona co najwyżej uśmiech politowania, bo „zegar w zegar” układ ten jest teraz nawet słabszy od Corteksa-A53. Wydajność jedno- i wielowątkowa jest po prostu słaba i to dobrze, że Qualcomm stworzył Kryo niemal od zera, bo dzięki temu nowa architektura mobilnego giganta jest ponad dwa razy szybsza „zegar w zegar” od starej. Byłoby fajnie, gdyby pewna zielona firma znana z tworzenia procesorów desktopowych potrafiła dokonać czegoś podobnego ;)
ARM kontra Linux
To jednak nie koniec naszych testów i porównania wydajności układów ARM i x86. Poznajcie Jetsona TX1:
Jest to platforma deweloperska Nvidii oparta na Tegrze X1 z 4 GB pamięci DDR4 – czyli tej samej, która jest montowana w konsoli Shield TV. Jetson TX1 ma pewną bardzo ważną zaletę: na jego 16-gigabajtowym nośniku eMMC zainstalowano Ubuntu 14.04 (od niedawna w 64-bitowej wersji). A to pozwoliło nam wykonać pewne testy, których nie moglibyśmy uruchomić na smartfonie lub tablecie.
Żeby zbadać linuksową wydajność procesora zamontowanego w Jetsonie TX1, skorzystaliśmy z wybranych testów narzędzia Phoronix Test Suite w wersji 6.4.0 i porównaliśmy wyniki z osiągami kilku platform x86, na których również zainstalowaliśmy Ubuntu 14.04. Na główny punkt odniesienia wybraliśmy Phenoma II X4 975, którego spowolniliśmy do 2 GHz, czyli do częstotliwości, z którą taktowane są duże rdzenie Tegry X1. Dlaczego akurat Phenom II? Potrzebowaliśmy starszego desktopowego procesora o dobrze wszystkim znanej wydajności, którą można w miarę łatwo odnieść do wyników współczesnych jednostek centralnych (na przykład podczas lektury naszych artykułów o tym, jak zmieniała się wydajność procesorów Intela i AMD). Niestety, nie mieliśmy dostępu do procesora pokroju Q6400 (cztery rdzenie Conroe taktowane z częstotliwością 2,13 GHz) i platformy LGA775, które to zapewne spisałyby się lepiej w tych zastosowaniach. Jest to rozwiązanie dalekie od ideału i wiemy, że przydałaby się znacznie obszerniejsza baza wyników, ale ze względów czasowych i technicznych (o których więcej za chwilę) zdecydowaliśmy się poprzestać na tym, co widzicie poniżej.
Na początek jedna bardzo ważna obserwacja. Porównajcie wyniki uzyskane w 7-Zipie przez Jetsona TX1 z osiągami konsoli Shield TV, które można znaleźć na poprzedniej stronie tego artykułu. Podpowiemy, że Jetson osiąga 3863 MIPS, a Shield TV – 6586 MIPS. Ten sam benchmark, ten sam procesor, ale inny system i sposób kompilacji. Co ciekawe, zmiana systemu i kompilatora nie zaszkodziła platformom x86, których wyniki zamieszczone na poprzedniej stronie zostały uzyskane w Windows i nie różnią się zbytnio od rezultatów widocznych powyżej. Podobnie duże różnice można zauważyć podczas analizy wyniku testu x264: Jetson TX1 odstaje w nim od Phenoma II taktowanego z częstotliwością 2 GHz znacznie bardziej (o mniej więcej 33%) niż Shield TV (niecałe 17%). Oczywiście, w przypadku testu x264 dochodzą jeszcze inne czynniki i nie jest to aż tak bezpośrednie porównanie jak w przypadku 7-Zipa (trochę inne ustawienia kodowania, inny plik testowy itd.), jednak daje to do myślenia.
Spostrzeżenia te wskazują, że testy składające się na Phoronix Test Suite uruchomione w Ubuntu zainstalowanym w Jetsonie TX1 z jakiegoś powodu mogą nie pokazywać pełni możliwości Tegry X1. Nie wiemy, czy jest to kwestia użytego kompilatora, przypadłość systemu platformy deweloperskiej Nvidii czy jeszcze innego czynnika, nad którym nie mamy kontroli. Dlatego podchodzimy do powyższych wykresów ze sporą rezerwą.
Nawet jeśli Phoronix Test Suite i Jetson TX1 nie są najlepszym połączeniem i Tegrę X1 stać na więcej, niż wskazują powyższe słupki, to i tak pokusimy się o wyciągnięcie pewnych wniosków.
Przede wszystkim powyższe wykresy dobrze pokazują, jak dużo zależy od doboru testów. W niektórych z nich (C-Ray, MAAFT, x264) Tegra X1 wypada bardzo dobrze i zbliża się na niewielką odległość do 2-gigahercowego Phenoma i mobilnych procesorów Intela, co sugeruje, że nowsze i szybsze architektury, takie jak: ARM Cortex-A72, ARM Cortex-A73, Qualcomm Kryo, powinny w nich dogonić (lub nawet przegonić) Phenoma II. A to oznacza, że najnowsze smartfony nie mają pod względem wydajności daleko do procesora Intel Core 2 Quad Q6400.
Natomiast w innych wygląda to znacznie gorzej. Skrajne przypadki to test szyfrowania Open SSL i test SmallPT (renderowanie globalnej iluminacji). Przypominają nam one o tym, że często programista ma więcej do powiedzenia w kwestii wydajności architektury procesora od jego twórców.
Mimo to widzimy, że moc obliczeniowa smartfonowych i tabletowych procesorów powoli zbliża się do tego, co kilka lat temu było zarezerwowane dla desktopów i drogich laptopów, więc wizja smartfona wkładanego do biurkowej stacji dokującej z myszką, klawiaturą i monitorem, pozwalającego na w miarę komfortową pracę, staje się coraz klarowniejsza. Tylko jeszcze trzeba popracować nad throttlingiem, kompilatorami i optymalizacją kodu pod kątem architektur innych niż x86, bo te czynniki wyraźnie stoją na drodze układów ARM.
Smartfonowe układy graficzne
W artykule omawiającym procesory ARM nie można pominąć ich niemalże nieodłącznych towarzyszy, czyli układów graficznych. Choć czipy ARM to nie tylko smartfony, tablety i konsole, to jednak większość z nich ma zintegrowany jakiś GPU i dobrze jest wiedzieć, który z nich jest w tej chwili najlepszy i jak mobilne układy graficzne rozwijały się w kilku ostatnich latach.
W tej chwili na graficznym polu bitwy pozostało czterech głównych graczy, choć zdecydowaną większość rynku kontroluje dwóch z nich: Qualcomm i ARM. Powody takiego stanu rzeczy są dość oczywiste. Każdy Snapdragon projektowany przez Qualcomma ma zintegrowany jakiś układ graficzny należący do rodziny Adreno, ARM zaś oferuje licencję na układy Mali każdemu nabywcy licencji na architekturę ARM – i to po bardzo okazyjnej cenie. To pozostawia bardzo niewiele miejsca jakiejkolwiek konkurencji. Dlatego niegdyś często spotykane i chwalone układy graficzne PowerVR można znaleźć niemal tylko w czipach Apple (i czasem w jakimś Atomie lub MediaTeku).
A Nvidia? Nvidia nie może powtórzyć rynkowego sukcesu Tegry 2 i 3. Z tego powodu strategia firmy trochę się zmieniła i nowsze Tegry (a więc również ich układy graficzne) częściej znajdują chętnych w branży motoryzacyjnej niż na rynku smartfonów i tabletów.
Która z tych firm oferuje najszybsze produkty? To bardzo trudne pytanie, gdyż bardzo dużo zależy od implementacji. O ile w przypadku układów graficznych Qualcomma sytuacja jest dość jasna, o tyle w przypadku ARM, PowerVR i Nvidii trzeba wziąć pod uwagę kilka istotnych czynników.
- Specyfikacja architektury ARM Mali-T880 zakłada istnienie konfiguracji składających się z 16 klastrów obliczeniowych, a najmocniejsza istniejąca implementacja (Exynos 8890 z Galaxy S7) ma ich tylko 12.
- Specyfikacja architektury serii 7XT zakłada istnienie 16-klastrowych konfiguracji, a najmocniejsza jej implementacja (Apple A9X z iPada Pro) ma ich tylko 12.
- Tegra X1 montowana w konsoli Shield TV zużywa 10–15 W, czyli ponad dwa razy więcej niż A9X z iPada Pro.
Zacznijmy więc od najłatwiejszego tematu. Jeśli chcesz kupić smartfon z najwydajniejszym układem graficznym, to powinien to być sprzęt ze Snapdragonem 820. Jego przewaga nad 12-rdzeniową wersją Mali-T880 i 6-rdzeniową odmianą PowerVR 7XT nie jest jednak duża. To bardzo interesujące, że trzy konkurencyjne i zupełnie inne architektury mają tak zbliżoną wydajność.
Jeszcze ciekawszy materiał do analizy zapewnia porównanie wyników Tegry X1 i najmocniejszej istniejącej implementacji architektury PowerVR 7XT. (Ciekawszy ze względu na pewien sentymentalny powrót do pojedynków GeForce kontra Kyro ;)). Wynika z niego, że Imagination Technologies na razie ma pewną przewagę nad Nvidią. Oczywiście, jeszcze musimy poczekać na pierwszy 16-nanometrowy SoC „zielonych” i pierwszy układ graficzny tej klasy oparty na nowej architekturze Pascal (GPU Tegry X1 jest zbudowany w architekturze Maxwell), ale osiągnąć współczynnik zużycia energii do wydajności, który zapewniały układy PowerVR, nie będzie łatwo. Tegra X1 z Shield TV wygląda pod tym względem naprawdę kiepsko, a odmiana tego czipu montowana w tablecie Google Pixel C jest o mniej więcej 1/3 wolniejsza. A przecież w tym roku powinniśmy już zobaczyć pierwsze implementacje najnowszej architektury Imaginations Technologies. Należy się więc spodziewać, że GPU nowej generacji iPadów nadal będą miały bezpieczną przewagę w wydajności nad ich ARM-ową konkurencją.
Pozostał nam jeszcze jeden temat do omówienia: degradacja wydajności. Powyższy zestaw wykresów przedstawia maksymalne możliwości poszczególnych układów graficznych, ale maksymalny w przypadku większości współczesnych smartfonów i tabletów wcale nie oznacza typowy. Urządzenia tych rozmiarów mają bardzo ograniczone możliwości odprowadzania ciepła, a więc montowane w nich procesory mają ograniczony budżet energetyczny. Niestety, od dłuższego czasu mało kto bierze go poważnie pod uwagę, przez co układy graficzne najwydajniejszych smartfonów muszą być spowalniane, żeby obudowy naszych gadżetów nie nagrzewały się nadmiernie. Jak bardzo? Nawet o kilkadziesiąt procent.
Na zakończenie mała ciekawostka. Ostatnie miejsce we wszystkich testach zajmuje Adreno 306 z popularnego Snapdragona 410. Układ ten jest średnio o kilkanaście procent szybszy od GPU Samsunga Galaxy S III. Polecamy małą gimnastykę umysłową i policzenie, ile razy wzrosła wydajność mobilnych układów graficznych w ciągu ostatnich 4 lat :)
Nvidia Shield TV kontra... Xbox 360
Spróbujmy przenieść znajdujące się na poprzedniej stronie wyniki z próżni w miejsce, w którym powiedzą nam coś więcej. Jak te wszystkie słupki i punkty mają się do tego, co mogą osiągnąć desktopowe układy graficzne i... konsole? Najłatwiejszym sposobem, by to ocenić, będzie analiza wyników Tegry X1, której układ graficzny jest pochodną architektury GeForce'ów z serii 700 i 900.
Tegra X1 | GeForce GTX 750 | |
---|---|---|
Jednostki cieniujące | 256 | 512 |
ROP | 16 | 16 |
Jednostki teksturujące | 16 | 32 |
Taktowanie rdzenia | ~1000 MHz | 1020-1085 MHz |
Moc obliczeniowa | ~512 gigaflopów | ~1095 gigaflopów |
Szyna pamięci | 64 b | 128 b |
Przepustowość pamięci | 25,6 GB/s | 80 GB/s |
Jak widać w powyższej tabeli, GPU Tegry to – z pewnymi wyjątkami – połowa układu z GTX-a 750. Ten GPU nie ma bezpośredniego odpowiednika wśród układów wykorzystywanych w tanich kartach graficznych Nvidii, ale można się pokusić o oszacowanie jego wydajności. Zapewne wynosi ona mniej więcej 30–40% wydajności wspomnianego GTX-a (w zależności od tego, na ile dany test zależy od efektywności podsystemu pamięci, który w Tegrze jest bardzo ograniczony). To oznacza, że Nvidia Shield TV ma wydajność graficzną zbliżoną do osiągów GeForce'a GT 740 DDR3 lub mobilnego GeForce'a GT 740M. Szybki rzut oka na bazę wyników w 3D Marku i GFXBenchu potwierdza, że te karty osiągają rezultaty zbliżone do wyników GPU Tegry X1. Przy okazji oznacza to wydajność zbliżoną do możliwości Radeona HD 4670, który przecież pozwalał niegdyś pograć w pierwszego Crysisa w rozdzielczości HD w średnich ustawieniach jakości obrazu.
Co jednak ważniejsze, oznacza to, że GPU Tegry X1 ma większą moc obliczeniową niż GPU konsol poprzedniej generacji. PlayStation 3 ma zaprojektowany przez Nvidię układ graficzny RSX, będący pochodną GPU montowanego w GeForsie 7800GTX, a Xenos Xboksa 360 to projekt ATI, który ma dużo wspólnego z architekturą Radeonów X1800. Oczywiście, należy pamiętać – co za chwilę wykażemy – o tym, że wydajność nie zależy jedynie od czystej mocy obliczeniowej i że w grę wchodzi wiele innych czynników. Trudno też ocenić wydajność procesora Tegry na tle procesorów montowanych w Xboksach 360 i PS3. Jednak w teorii najwydajniejsze urządzenia przenośne powinny zapewniać jakość grafiki zbliżoną do tego, do czego kilka lat temu byli przyzwyczajeni konsolowi gracze siadający wieczorem przed swoimi kilkudziesięciocalowymi telewizorami. Czy tak faktycznie jest? Sprawdziliśmy to.
Nvidia zadbała o to, by na konsolę Shield TV przeniesiono kilka tytułów gier znanych z pecetów i standardowych konsol. Wybraliśmy cztery z nich: Doom 3 BFG, Half-Life 2: Episode 2, Metal Gear Rising: Revengeance i Borderlands: The Pre-Sequel. Sprawdziliśmy, jak wyglądają i działają na konsoli Nvidii i na Xboksie 360. Do oceny płynności animacji na tych dwóch konsolach wykorzystaliśmy te same metody, którymi się posługujemy, tworząc cykl artykułów „Konsole kontra PC”. Swoją drogą, jest to bardzo ciekawy temat w kontekście niedawnych informacji o tym, że procesor Nvidii ma trafić do najnowszej konsoli Nintendo.
Doom 3 BFG
Doom 3 to już dość leciwa gra i czasy, gdy uruchomienie jej na pececie było wyzwaniem, są już dawno za nami. Gra ta pokazuje jednak, ile można wyciągnąć z Tegry X1, jeśli ktoś się przyłoży do optymalizacji kodu. Co prawda obie wersje gry działają niemal idealnie płynnie (60 kl./sek.), ale Doom 3 na Xboksie 360 jest renderowany w rozdzielczości 720p, natomiast na Shield TV – w rozdzielczości Full HD. Wersja Shield TV cechuje się też wyższym stopniem filtrowania anizotropowego tekstur. Reszta efektów zdaje się wyglądać bardzo podobnie. Krótko mówiąc, Doom 3 lepiej wygląda i działa na konsoli Nvidii niż na konsoli Microsoftu.
Half-Life 2: Episode 2
W Half-Life 2: The Cliffhanger Episode 2 Shield TV wypada jeszcze lepiej – przewaga tej konsoli nad Xboxem jest niepodważalna. Gra nie tylko jest renderowana w wyższej rozdzielczości (1080p zamiast 720p), ale ma też znacznie lepszej jakości tekstury. Wersja xboksowa wręcz wygląda, jakby cały jej świat był spowity w mgle. Także płynność animacji jest różna, ale tutaj już trudno ocenić, czy można mówić o przewadze Shielda. Wersja xboksowa jest zablokowana na 30 kl./sek. i rzadko schodzi poniżej tego poziomu. Natomiast wersja na Tegrę X1 może działać z szybkością 60 kl./sek., ale w czasie walki i ogólnie na bardziej otwartych poziomach nie udaje się jej utrzymać, co w połączeniu z zawsze aktywną synchronizacją pionową przyczynia się do niezbyt przyjemnych wrażeń płynących z gry i mniejszej precyzji sterowania. Mimo to porównanie w Half-Life 2: Episode 2 przynosi kolejną wygraną Shield TV.
Borderlands: The Pre-Sequel
Borderlands: The Pre-Sequel to jedna z bardziej wymagających i nowszych gier działających na Shieldzie. Obie testowane przez nas wersje wyglądają podobnie i są renderowane w rozdzielczości HD, ale wersja na Shielda ma jedną zasadniczą przewagę: włączone wygładzanie krawędzi. W tej grze, w której wszystkie kontury są grube, wyraźne i odcinają się od tła, robi to ogromną różnicę. Tak samo jak w przypadku Half-Life'a płynność animacji na Xboksie jest zablokowana na poziomie 30 kl./sek., a Shield pozwala liczyć na 60 kl./sek., ale tylko wtedy, gdy... patrzy się prosto w ścianę, bo w każdej innej sytuacji bliżej jest do 40 kl./sek. Po tej grze jednak znowu widać, że konsolowa jakość grafiki na tablecie to nie oksymoron.
Metal Gear Rising: Revengeance
Metal Gear Rising: Revengeance przypomina jednak, że teoretyczna moc obliczeniowa to nie wszystko. Gra ta jest również sporym wyzwaniem dla podsystemu pamięci i procesora, które to nie są mocnymi stronami SoC-a Nvidii. Jakość obrazu w przypadku obu konsol jest właściwie taka sama, obie renderują tę grę w rozdzielczości 720p, ale Shield zapewnia znacznie, ale to znacznie gorszą płynność animacji. Gdy na ekranie dzieje się trochę więcej (a właściwie ciągle coś się dzieje, na przykład wybucha), zaczynają się pojawiać spadki do około 20 kl./sek., co w grze tego typu jest bardzo dużym problemem. Co prawda Xboksowi nie udaje się utrzymać stałych 60 kl./sek., ale i tak gra się o wiele przyjemniej.
Wnioski
Dwa wyraźne zwycięstwa Shield TV, jedno mniejsze i jedna duża przegrana. Dowiedzieliśmy się stąd, że układy graficzne najwydajniejszych ARM-owych SoC-ów faktycznie pozwalają osiągnąć lepszą jakość grafiki niż GPU konsol poprzedniej generacji. Dowiedzieliśmy się też, że na mocy obliczeniowej historia się nie kończy, bo jednak ograniczona wydajność procesora, przepustowość pamięci współdzielona przez CPU i GPU, a także typowe problemy z „portowaniem” gier jeszcze przez jakiś czas nie pozwolą zagrać w pełnowartościowe wersje Uncharted i Halo na smartfonie lub tablecie. Do niedawna pewnym problemem były też niedostatki API dostępnych na mobilne platformy. Tak naprawdę Shield TV i konsole Nvidia Shield to jedne z niewielu urządzeń z Androidem z pełną obsługą pełnej wersji OpenGL, a nie OpenGL ES, to zaś zniechęca do przenoszenia „prawdziwych” gier na platformę Google. Na szczęście Android Nugat przynosi obsługę Vulcana, więc jeśli tylko producenci mobilnych GPU przyłożą się do pisania sterowników, będzie szansa na poprawę tej sytuacji. API to powinno także pomóc w ukryciu niedoborów wydajności procesorów ARM. Przyszłość mobilnego grania wygląda więc bardzo interesująco.
Co dalej?
Ostatnich kilka lat rozwoju procesorów ARM to historia sukcesu. Owszem, w pewnej mierze jest on zasługą... Steve'a Jobsa i pierwszego iPhone'a, bo to właśnie ten gadżet i jego główny pomysłodawca stworzyli bardzo żyzne poletko dla wszelkich ARM-ów, na którym rozwijają się one jak na najlepszych nawozach. Jednak przede wszystkim jest to efekt pracy inżynierów ARM i bardzo elastycznego modelu biznesowego, dzięki któremu nad kolejnymi generacjami czipów opartych na architekturze ARM pracowali nie tylko ludzie z ARM, ale również tęgie głowy licencjobiorców.
Zapewne niektórzy z Was jeszcze pamiętają czasy urządzeń z procesorami ARM11 i ogromny wzrost wygody użytkowania wynikający z przesiadki na sprzęt z pierwszymi Corteksami i Snapdragonami. A przecież najnowsze architektury ARM są „zegar w zegar” ponad dwa razy wydajniejsze od Corteksów-A9 i A8 sprzed kilku lat. Do tego procesory ARM mają więcej rdzeni i są coraz szybciej taktowane, co w sumie przekłada się na kilkunastokrotny wzrost wydajności czipów ARM w ciągu ostatniej dekady. Jeszcze szybciej wzrasta wydajność mobilnych układów graficznych, które mają dziś większe możliwości od GPU z konsol poprzedniej generacji. Z naszej analizy wynika, że obecnie najwydajniejsze czipy ARM montowane w smartfonach i tabletach mają moc obliczeniową 10-letniego peceta wysokiej klasy, a to daje pewne wyobrażenie o możliwościach naszych kieszonkowych komputerów.
Jednak utrzymanie takiego tempa rozwoju będzie bardzo trudne, lub wręcz niemożliwe. Procesory ARM w pewnym stopniu idą ścieżką, którą na przełomie wieków przeszły procesory x86. Mają już za sobą najbardziej oczywiste i najbardziej istotne zmiany, które wcześniej mogli docenić użytkownicy biurkowych jednostek centralnych: poszerzenie architektury, przejście na wykonywanie instrukcji poza kolejnością oraz wprowadzenie wielordzeniowości. Teraz będzie znacznie trudniej znaleźć nowe, rewolucyjne rozwiązania, które zapewnią zwielokrotnienie wydajności. Już obecne „duże” rdzenie ARM są na tyle duże, że bez połączenia ich z mniejszymi, prostszymi nowoczesne procesory ARM straciłyby jeden ze swoich najważniejszych atutów: energooszczędność. Po ich zachowaniu widać też, że często nie biorą one do końca pod uwagę ograniczeń termicznych urządzeń, w których są montowane. Mocne spowolnienie nastąpiło również w rozwoju technik produkcji półprzewodników, więc wygląda na to, że na drodze do poszerzania architektury ARM i przyspieszania zegarów taktujących zbudowane w niej rdzenie stanęła bezlitosna fizyka.
Krótko mówiąc, można sądzić, że złoty okres lawinowego wzrostu wydajności mamy już za sobą. Przed nami raczej otwiera się okres stopniowej optymalizacji, z którym od kilku lat muszą się godzić pecetowi zapaleńcy ;) Na znaczeniu będą też zyskiwały nie te największe i najwydajniejsze układy, a te najmniejsze i najbardziej energooszczędne, które mają stanowić o przyszłości Internetu Rzeczy.
Chyba że procesory oparte na architekturze ARM faktycznie mają na poważnie zaatakować rynek serwerów, na którym panują inne zasady i rządzą inne limity TDP. Wiele osób właśnie w chęci ekspansji na nowe, trudne rynki doszukuje się powodów niedawnej sprzedaży ARM w ręce japońskiego Softbanku. Czy to się uda? Z jednej strony ARM-om udało się odeprzeć atak x86 na rynek procesorów smartfonowych. Z drugiej zaś to ARM będzie tym razem nowym graczem, który ma przekonać wszystkich, że oferuje coś, czego nie oferuje konkurencja. Przekonać integratorów, inżynierów, administratorów i – przede wszystkim – programistów, że przesiadka na architekturę ARM da im coś, czego teraz nie dają im Xeony, Itanium, PowerPC, Sparcki i inne. A to nie jest łatwe i bardzo nas ciekawi, jak układom ARM będzie szło wypływanie na te nowe, niezbadane wody i skalowanie się w górę. Bo to, że potrafią zdziałać cuda, gdy się im założy 5-watowy kaganiec, wiemy już od dawna. A co się stanie, gdy się go zdejmie?