A ja zapytam – i co z tego? Na początku chciałbym jednak wyjaśnić: nie mam nic przeciwko 8 czy nawet 16 rdzeniom, tak samo jak nie mam nic przeciwko 2 czy 4 rdzeniom. Podobnie jest z architekturą 32 i 64 bit.
Do napisania tego felietonu skłoniło mnie zachowanie producentów podczas targów MWC w Barcelonie. Rozumiem rozwój technologiczny oraz reguły jakimi rządzą się działania marketingowe, ale trudno mi się zgodzić na ogłupianie klientów i użytkowników pustymi sloganami. To żadna nowość w niemal każdej z gałęzi rynku, ale z jakiegoś powodu od producentów elektroniki użytkowej oczekiwałbym więcej. Odrobiny szacunku dla odbiorcy.
OSIEM RDZENI!!!!!!!!!!!!!!111jeden
Najważniejsza cecha nowego smartfona? Osiem rdzeni! Osiem! Rozumiesz?! Osiem rdzeni! Wystarczy popatrzeć na stoiska i ulotki reklamowe, a zrozumiemy o co chodzi. Oczywiście nie twierdzę, że producent powinien zatajać liczbę rdzeni procesora, ale każdy średnio obeznany w technologiach osobnik rozumie, że ich liczba jest elementem drugo a nawet trzeciorzędnym. I nie chodzi mi tylko o taktowanie pojedynczego rdzenia, ale przede wszystkim o architekturę, parametry termiczne, GPU (przecież grafika też ma rdzenie, dlaczego prawie nikt tego nie podaje?). A rdzenie DSP? Dlaczego nikt ich nie liczy? Fixed function processing i rdzenie tej jednostki? Również nie… Tak wiele zależy od architektury, zbioru instrukcji procesora, optymalizacji taktowania, ale elementy te są mało „marketingowe”. Trudno je sprzedać. A 8 rdzeni? OSIEM RDZENI!!! To robi wrażenie. Mimo tego, że nie mam nic przeciwko 8-rdzeniowcom, warto rozprawić się z pewnym mitem. 8 rdzeni po 1,5 GHz nie da nam wydajności jednego rdzenia 12 GHz. Bardzo (BARDZO) mało aplikacji potrafi korzystać z więcej niż dwóch rdzeni (na raz), a większość z nich w pełni korzysta tylko z jednego.
Trochę lepiej sprawa wygląda z systemem operacyjnym, w którym uruchamia się wiele procesów i wątków, ale dalej, nawet w tym przypadku, 8 rdzeni to wyciąganie zbyt dużej armaty. Biorąc pod uwagę aplikację jednowątkową, pojedynczy wątek nie może być obsługiwany na kilku rdzeniach jednocześnie. Co prawda może być odpalany na różnych rdzeniach jeden po drugim, ale nie odbywa się to symultanicznie. Producenci tacy jak Qualcomm stworzyli technologię, która pozwala na jednoczesne odpalanie wątku na wielu rdzeniach, ale sprowadza się to do podziału go na pod-wątki, a wydajność, którą dzięki temu zyskujemy jest marginalna. Chcąc w pełni wykorzystać rdzenie procesora, twórcy musieliby pisać aplikacje z asynchronicznymi wątkami, które pozwoliłyby na ich zrównoleglanie – co jak na razie jest rzadkością (poza niektórymi grami). I nie wynika to z lenistwa programistów – wielu algorytmów i kawałków kodu po prostu nie da się zrównoleglić używając obecnego paradygmatu programistycznego.
64 bity, czyli jestem dwa razy szybszy
Nie, nie jesteś, choć producenci chcieliby, żebyś właśnie takie odniósł wrażenie. Temat 32 i 64 bitów jest dużo bardziej złożony. Jeden obóz twierdzi, że 64 bity potrzebne są tylko po to, żeby zaadresować więcej niż 4 GB pamięci RAM, bo na procesorze 32 bit jest to niemożliwe. Drugi obóz próbuje wmówić nam, że przejście na 64 bity w magiczny sposób przyspieszy działanie systemu i aplikacji. Moim zdaniem obie grupy zasadniczo się mylą. Większość czytelników zapewne spotkało się z twierdzeniem, że procesor 32-bitowy nie może zaadresować więcej pamięci operacyjnej niż 4 GB (a w praktyce jeszcze mniej, z uwagi na zastrzeżoną przestrzeń adresową).
Skąd wynika to ograniczenie? Z prostego rachunku: 32 bity określają liczbę możliwych do zaadresowania komórek. Istnieje 2^32 wariacji 32-bitowego adresu, czyli bezpośrednio można adresować 4 294 967 296 (4 G) komórek pamięci. Czy jednak rzeczywiście stanowi to problem nie do przejścia dla 32-bitowej architektury? Niekoniecznie. Od dawna znane są rozwiązania zwiększenia przestrzeni adresowej np. przez zastosowanie segmentacji lub wirtualizacji pamięci – użycie PAE (Physical Adress Extension). Rozwiązanie to pozwala procesorowi na dostęp do więcej niż 4 GB pamięci RAM, ale nie zmienia rozmiaru wirtualnej przestrzeni adresowej dla pojedynczego procesu – każdy proces w pamięci będzie dalej ograniczony limitem 4 GB. Nie chodzi zatem jedynie o problemy związane z wielkością pamięci RAM.
Przejdźmy zatem do tego czym jest 64-bitowa architektura. Procesory wykorzystują dwa typy liczb do wykonywania operacji takich jak dodawanie, mnożenie, przesuwanie i kopiowanie danych do pamięci – liczby całkowite i liczby zmiennoprzecinkowe (ułamki dziesiętne). Jeśli procesor radzi sobie z tymi operacjami dla ciągów całkowitoliczbowych o długości do 16 bit, jest procesorem 16-bitowym. Jeśli do 32 bit – procesorem 32-bitowym. I tak dalej. 32-bitowy procesor używa też 32 bitów do wskazywania na obszary pamięci, podczas gdy procesor 64-bitowy używa do tego 64 bitów. To znaczy, że pojedynczy program (a właściwie proces) może zaadresować na swoje potrzeby jedynie 4 GB w przypadku czipu 32-bitowego, nawet jeśli cały procesor (a nie jeden proces) może zaadresować więcej. Procesor 64-bitowy dzięki 64-bitowej przestrzeni adresowej, może zaadresować dla każdego pojedynczego procesu do 16 eksabajtów pamięci. Ile to jest? Dużo, dużo, dużo więcej niż będziesz kiedykolwiek potrzebował.
Dla większości aplikacji, czysta korzyść z procesora 64-bitowego jest niezauważalna. Większość appek nie potrzebuje wykonywać 64-bitowych operacji ani adresować więcej niż 4 GB RAM (tak wiem, do czasu), a obecne smartfony mają maksymalnie 4 GB tej pamięci, która mogłaby być z powodzeniem obsłużona przez procesor 32 bit. W praktyce, aplikacje 64-bitowe czasami mogą chodzić wolniej niż ich 32-bitowe odpowiedniki, z uwagi na to, że używanie tych 64-bitowych wskaźników pamięci zwiększa zasobożerność aplikacji, jeśli chodzi o stos, RAM i pamięć cache. Zalety? Są, ale korzyści obecnie – prawie niemierzalne. Architektura ta dostarcza więcej rejestrów, które są dwa razy szersze, co teoretycznie przyczynia się do wzrostu wydajności aplikacji, które są skompilowane dla 64 bitów.
64 bity – ukryta korzyść
Największa zaleta przesiadki na 64-bitową architekturę nie jest bezpośrednia. Wynika ona z przejścia na nowy, udoskonalony zbiór rozkazów dla procesorów ARM, czyli przejścia z ARMv7 na architekturę ARMv8. v7 był z nami już prawie dekadę i niemalże domagał się ulepszonego następcy. ARMv8 optymalizuje rozkazy, pozbywa się tych nieoptymalnych, zastępując je bardziej wydajnymi. Niektóre rozkazy są niejako skrojone na miarę dla nowych appek i ich potrzeb – między innymi wydajne szyfrowanie czy przetwarzanie sygnałów. Podwojona liczba rejestrów w tej architekturze pozwala na rzadsze odwołania do pamięci – i nie jest to zasługa 64-bitów, a zasługa ARMv8. Podsumowując – to ARMv8 sprawia, że 64-bitowe procesory mogą być wydajniejsze, a nie sam fakt posiadania dwa razy dłuższych rejestrów. Co prawda nie ma v8 bez 64 bitów, ale marketingowy nacisk na „64” jest zdecydowanie wyolbrzymiony.
Czy zatem realna korzyść z 64 bitów jest zauważalna i mierzalna? I tak i nie. Nadal najważniejsze będzie taktowanie procesora i jego wewnętrzna architektura, a nie długość rejestru. 64-bitowy Snapdragon 410 będzie zauważalnie wolniejszy niż 32-bitowy Snapdragon 805. W zderzeniu z GHz, procesem litograficznym, rodzajem rdzeni, GPU i wewnętrzną architekturą ani dłuższy rejestr, ani ARMv8 nie ma szans. Oczywiście przejście na 64 bity, a przede wszystkim właśnie na ARMv8 było nieuniknione i niewątpliwie pozytywne, ale nie powinniśmy przypisywać temu magicznego znaczenia. Trzeba pamiętać, że do pełnego wykorzystania 64 bitów potrzebujemy 64-bitowego systemu operacyjnego np. Lollipop) i 64-bitowych aplikacji skompilowanych/napisanych dla tej architektury.
Android zrobił pierwszy krok, choć nie obyło się bez potknięć, a wiele osób narzeka na wydajność systemu na 64-bitowcach i na brak pełnej kompatybilności wstecznej. Problemem pozostają wciąż aplikacje. Co prawda ich twórcy zapewne zoptymalizują je wkrótce pod 64-bitowe czipy, jednak problem jest tak naprawdę gdzieś indziej. Aplikacje na Androida oparte są w głównej mierzę o Javę. Ściągając .apk, ściągamy tak naprawdę skompresowane archiwum z kodem i bibliotekami, podczas gdy system kompiluje je JiT (Just in Time – Dalvik) lub AoT (Ahead of Time – ART). Jeśli ART w Lollipopie nie przyniesie wewnętrznej optymalizacji do natywnego kodu 64-bitowego, wysiłki producentów będą daremne. A na razie Google ma z tym kłopot, jak pokazuje wiele syntetycznych benchmarków.
Do końca tego roku zapomnicie o 64 bitach
Marketingowcy kochają termin 64-bit i octacore. Terminy takie jednak bardzo szybko przestają ekscytować, tak jak kiedyś przestały ekscytować nas megapiksele czy megaherce. Przesiadka z 32 na 64 bity czy z 4 na 8 rdzeni nie podwoi wydajności, tak jak 20 megapikseli nie będzie „dwa razy lepsze” niż 10 megapikseli. 20 megapikseli to… po prostu dwadzieścia milionów punktów na matrycy. Tylko i aż tyle. Tak jak 64 bity i 8 rdzeni. Nie ma tu magii, wbrew temu, do czego próbują nas przekonać całe sztaby marketingowców z największych na świecie firm technologicznych. A ja mimo wszystko naiwnie chciałbym, żeby traktowały one swoich klientów poważnie i z szacunkiem.
