Długoletni stażem użytkownicy Macintoshy na kolejne doniesienia o możliwym przejściu na nową architekturę procesorów na ich platformie wzruszają tylko ramionami i pytają „Znowu?”. Apple ma długą tradycję w przeprowadzaniu takich rewolucji. Najstarsi użytkownicy pamiętają przejście z architektury 68k (CISC) na PowerPC (RISC), porzucenie PowerPC na rzecz Intela (znowu CISC). W międzyczasie była też całkowita zmiana architektury systemu z macOS 9 na X.
Po tych wszystkich doświadczeniach, do kolejnych zmian Apple przygotowywało się systemowo, tworząc swoje środowisko tak, aby było jak najbardziej niezależnym od architektury procesora. Może okazać się, że zwykły użytkownik nie odczuje prawie żadnych zmian, poza wydłużeniem czasu pracy laptopów z jabłkiem. Nie oznacza to, że taki proces będzie całkiem neutralny dla wszystkich.
Zacznijmy jednak od tego, jak i dlaczego Apple może zdecydować się na taki krok. Po pierwsze, dział projektowania procesorów w Apple jest jednym z najlepszych na świecie. Procesory ARM z jabłkiem, używane w iPhonach i iPadach bez problemu pokonują konkurencję spod znaku Qualcomm, Samsunga (Exynos) czy Huaweia (Kirin). Ich procesory są szybsze, lepiej zarządzają energią i mają znacznie lepsze, autorskie rozwiązania z zakresu bezpieczeństwa. W testach syntetycznych mobilne procesory z Cupertino dorównują, zużywającym znacznie więcej prądu, intelowskim procesorom i5.
Po drugie, coraz większe problemy z rozwojem swoich produktów ma od kilku lat Intel. Niedawny hegemon branży najpierw przegrał rynek mobilny, a dziś zaczyna tracić pole nawet na rynku desktopowym na rzecz odradzającego się AMD. Dla producenta takiego jak Apple taka stagnacja utrudnia projektowanie kolejnych wersji swoich produktów. Mapa drogowa Intela sprzed paru lat, obiecywała procesory szybsze, a jednocześnie bardziej energooszczędne niż to co widzimy dziś na półkach. Podczas gdy Intel powoli opanowuje litografię na poziomie 10 nm, producent układów Apple, tajwańskie TSMC wdraża 5 nm.
Po trzecie, jeszcze większym problemem Intela są krytyczne błędy bezpieczeństwa, które wykrywane są w coraz większej ilości. Spectre i Meltdown udało się jakoś załatać, obniżając przy okazji wydajność procesorów, ale ostatnio pojawiły się kolejne babole, których zdaniem specjalistów obejśc się nie da. Podejście do spraw bezpieczeństwa w Apple jest dość zasadnicze i może to być jednym z głównych argumentów za szybkim przejściem na własne konstrukcje.
Po czwarte, układy bazujące na ARM pełnią nawet dziś w Mackach bardzo ważne funkcje z zakresu bezpieczeństwa, akceleracji niektórych procesów czy zarządzania energią. Mowa tu o procesorach serii T. Połączenie na linii x86 - macOS - T2 nie jest jednak idealne. T2 pracuje pod kontrolą szczątkowego systemu zwanego BridgeOS, przy którego pośrednictwie następuje komunikacja z macOS i nie wszystko przebiega tam zgodnie z planem. Sporo użytkowników notuje zawieszenia systemu spowodowane jego pracą, także ludzie pracujący z dźwiękiem mają duże zastrzeżenia do pracy swojego oprogramowania na Makach wyposażonych w te procesory. Prawdopodobnie przejście całkowicie na ARM, pozwoliło by te procesy zintegrować bez konieczności zastosowania takiego „podsystemu” i poprawić stabilność całości.
Po piąte, rekompilacja sporej części oprogramowania powinna być relatywnie łatwa. macOS Catalina wymusiła na twórcach oprogramowania przejście na 64 bity, przy okazji obcinając wsparcie dla wielu starych API. Ci, którzy dostosowali oprogramowanie do nowych wymogów, zwłaszcza autorzy prostszych aplikacji, mogą nie odczuć żadnych niedogodności w trakcie tego procesu.
Pora teraz pogdybać, kto może ucierpieć na takiej rewolucji. Pierwszym kto przychodzi mi na myśl, są ludzie używający Maków multiplatformowo. Dość popularnym rozwiązaniem na przykład wśród programistów jest używanie macOS wraz z oprogramowanim typu Parallels Desktop czy VMware i równoległe używanie narzędzi pracujących pod kontrolą wirtualizowanych Windows czy Linuxa. Dziś, mając procesory Intela, jest to ułatwione, oprogramowanie korzysta bezpośrednio z rdzeni procesora. W przypadku przejścia na ARM konieczna będzie emulacja, a jak pokazuje przykład Windows na ARM, wydajność wtedy wyraźnie spada. Być może narzędzia Apple będą lepiej napisane, ale spadek wydajności jest nieunikniony.
Drugim poszkodowanym mogą być firmy produkujące bardziej zaawansowane oprogramowanie, bazujące na elementach komunikujących się bezpośrednio z warstwą sprzętową, plug-inach itp. Tam ryzyko błędów będzie znacznie większe, a co za tym idzie, koszty dostosowania wzrosną. Może to źle wpłynąć na chęć deweloperów do pozostania przy platformie. Już wspomniane przejście na 64 bity, spowodowało niemały eksodus, szczególnie wśród deweloperów specjalizujących się w oprogramowaniu dla branży audio.
Z tego względu uważam, że najlepiej byłoby, gdyby Maki z ARM funkcjonowały przez dłuższy czas równolegle z tymi opartymi na x86. Niech te procesory trafią do następcy MacBooka 12, dedykowanego dużo podróżującym czy podstawowych wersji MacBooka Pro dla użytkowników potrzebujących bardzo długiego czasu pracy na baterii. Reszcie zostawcie wybór, a deweloperom czas na dopracowanie narzędzi. W międzyczasie być może poprawi się też sytuacja Windows on ARM, co pozwoli uniknąć problemów z wirtualizacją.
Takie podejście dałoby zawodowcom stabilność, a zwykłym użytkownikom lepszy i dłużej działający sprzęt do konsumpcji treści. Biorąc pod uwagę, że zwykli użytkownicy i tak często przechodzą na iPada, może się okazać, że przyszłość Maka będzie ponownie zależna bardziej od użytkowników używających go w zaawansowany sposób. Nie warto podkładać im nogi, zwłaszcza że ostatnimi laty Apple i tak ich nie rozpieszczało. Na miejscu koncernu z Cupertino rozważyłbym za to, czy w przypadku x86 nie zainteresować się procesorami AMD, ponieważ Intel nie ma ostatnio dobrej passy i niewiele zapowiada, żeby miało się to zmienić.
Hej, jesteśmy na Google News - Obserwuj to, co ważne w techu
