Po premierze iPhone 5S we wpisie "MacBook Air na procesorze A8 - to będzie możliwe... " na podstawie analizy rozwoju procesorów ARM i Intela wysnułem teorię, że w najbliższym czasie być może będziemy świadkami kolejnej rewolucji, związanej z przejściem Apple na procesory ARM, a ściśle rzecz biorąc, na procesory Apple Ax zgodne z architekturą ARM. Moje hipotetyczne wówczas wyliczenia, dotyczące mocy obliczeniowej A7 były zbyt wysokie, jednak nie oznacza to, że jest to nie możliwe. Pod wpisem pojawiło się wiele pytań, wątpliwości i przemyśleń czytelników na które nie byłem często w stanie udzielić rzeczowych odpowiedzi. Nie jestem programistą i nie znam się kompletnie na tym, jak praca komputera i systemu wygląda od zaplecza. Dlatego też zaprosiłem do rozmowy na ten temat Jaromira Koppa.
Jaromir z platformą Apple jest związany jeszcze od czasów Motoroli 68000. Pisze własne aplikacje na iOS w tym świetny ponoć PistonCalc, który nawet zawędrował do Ekwadoru oraz PistonCalc na OS X. Prowadzi on własny blog - MacWyznawca. To oczywiście nie jedyny program napisany przez Jaromira, jednak PistonCalc zasługuje na szczególną uwagę. A ja zapraszam do zapoznania się z naszą rozmową, w której Jaromir wyjaśnia zagadnienia związane z ewentualną zamianą Intela na Apple Ax.

A więc pytanie pierwsze. Czy po wejściu procesora A7 są jakieś problemy z pisaniem aplikacji 64-bitowych?
Są i nie zarazem... Są ponieważ trzeba sprawdzić czy w naszych starych programach nie stosowaliśmy podejrzanych sztuczek, np. czy nie używaliśmy normalnych typów danych do przechowywania adresów (wskaźników) i kilka innych drobiazgów wskazanych dokładnie przez Apple w podręczniku konwersji na 64-bity. Drugim problemem jest to, że XCode 5.0 przy kompilowaniu na 32 i 64 bit jednocześnie (takie aplikacje Fat Binary) nie pozwala włączyć zgodności z iOS 6 (tylko iOS 7). Apple już to zmienia i taka kompilacja będzie możliwa. Pojawiła się wersja XCode 5.0.1 GM zgodna z nowym systemem OS X 10.9 Mavericks. Posiada ona już wsparcie dla kompilacji programów zgodnych zarówno z iOS 6 i iOS 7 w wersjach 32 i 64 bit jednocześnie. Są to jednak jedynie drobne trudności. Przypomnijmy sobie prezentację Infinity Blade III z 10 września. Wersja 64-bitowa została stworzona w 2 godziny przez jednego człowieka.

Jako developer posiadasz już O X 10.9. W nowym systemie Apple podobno jest jeszcze więcej wspólnych elementów z iOS.
Są, ale nie są nachalne. Doszły aplikacje iBooks i Mapy (bardzo fajne). Optycznie nie ma wielu różnic między OS X 10.8 i 10.9. Widać natomiast pewne tendencje zbliżające go do iOS, np. tagi w Finderze. W iOS tego nie ma, ale zmierza to w stronę zaniku dostępu do systemu plików dla zwykłego użytkownika, podobnie jak ma to miejsce obecnie w iOS. Oczywiście taki „zanik” systemu plików (okiem użytkownika) zajmie jeszcze kilka lat.

W sumie zawsze wychodziłem z założenia, że guzik mnie obchodzi w jakim katalogu system trzyma moje zdjęcia, muzykę itp. Ważne abym miał do tego dostęp kiedy potrzebuję.
No ja odwrotnie i to też za sprawą Apple. Jak zaczynałem przygodę z Maczkami, to dla mnie było piękne, że widzę gdzie każdy program jest i, że mogę go wywalić do śmietnika. Widziałem wszystkie pliki systemowe itp. W Windows nie wiadomo co gdzie jest i co gdzie było. No ale pewnie przywyknę. Do iPhoto i do iTunes już przywykłem.

Tak, ale Mac zawsze dbał o porządek. Pamiętasz jak się wrzucało na teczkę systemową równocześnie fonty, rozszerzenia itp. a on sam wszystko umieszczał we właściwych katalogach. Takie wrzucanie w Windows kończy się w najlepszym wypadku tylko bałaganem.
Dokładnie!

Będąc programistą widzisz jak iOS zbliża się do OS X. Myślisz, że będzie to jeden system, który będzie się instalował w wersji zależnej od urządzenia?
Widzę, że się zbliża ale bardzo rozsądnie i nigdy nie będzie to ten sam system! Apple nie powinno popełnić błędu Microsoftu. To byłoby bez sensu, bo to byłoby równanie w dół... Systemy zbliżają się, ale nie za wszelką cenę jak to obecnie robi Microsoft z Windows 8. Nie da się zrobić dobrze identycznego systemu na tak różne urządzenia. OS X 10.9 jest tak zewnętrznie podobny do 10.8, że nie czuje się zbliżenia do iOS zbyt mocno. Apple robi to rozsądnie i raczej ma plan rozwoju dwóch linii osobnych systemów. Od strony programisty, oba system mają wiele wspólnego, ale obsługa interfejsu tylko co do zasady jest podobna. Są całkiem inne kontrolki i elementy, inaczej reagują bo mamy mysz i wskaźnik a nie palec. No i dają znacznie więcej możliwości dla programisty w OS X niż w iOS.

Ok. Procesory Ax stają się coraz szybsze i może się zdarzyć, że Apple zechce je stosować w komputerach typu MacBook Air. Możliwe by było skompilowanie OS X na taką architekturę?
_A niby dlaczego tylko w Air? Łatwiej będzie przerobić OS X na ARM niż kiedyś z PowerPC na Intela, a Apple już to przecież zrobiło. No i jeszcze jedno... W iOS większość rzeczy poniżej interfejsu użytkownika jest identyczna co do API (funkcji systemu dla programow). Tak naprawdę Apple połowę systemu na ARM już ma gotowe w iOS. Znając ich, resztę już też w tajemnicy kompilują na ARM i testują podobnie jak to robili w tajemnicy przez 5 lat z wersją OS X dla Intela. Zawsze przy takiej zmianie architektury pojawiają się dwa problemy. Pierwszy to emulacja Intela na ARM aby zachować zgodność ze starymi aplikacjami kompilowanymi na Intela, na nowych, hipotetycznych komputerach z ARM. Przypuszczam że i to maja już rozpracowane, choć pozostaje kwestia wydajności. Problem drugi to przekonanie programistów do kompilowania na ARM, ale tej sztuki Apple w przeszłości dokonało już dwa razy, podczas przejścia z Motoroli na PowerPC i podczas zamiany PowerPC na Intela. Narzędzia są, programiści w 90% używają XCode, czyli gdy Apple wyda nową wersję swojego narzędzia dla programistów (XCode) przy niewielkich zmianach w programach lub nawet bez zmian, będzie można kompilować aplikacje z kodem na ARM i Intela jednocześnie, tak jak kompiluje się teraz na ARM 32 i 64 bit i jeszcze niedawno na PowerPC i Intela (Fat binary) Programista tego nawet nie zauważa.
_

No właśnie, ale gorzej z emulacją. Jakoś ciężko mi wyobrazić sobie, aby producenci gier zamiast portować gry z PC tak jak to ma teraz miejsce, pisali je od początku na ARM.
Za czasów PowerPC jakoś pisali gry! Zwróć uwagę na silniki do gier. Te najważniejsze mają swoje wersje dla iOS i to nawet częściej niż na OS X. Obecnie gry robi się „na silnikach”, a nie koduje od podstaw. No i jeszcze jedno. Apple bardzo sprytnie zagrało, wydając nowe API dla programistów: Sprite Kit, jednocześnie dla iOS 7 i OS X 10.9. Bardzo ułatwi to pisanie gier 2D na iOS i OS X równocześnie. To kolejna poszlaka, że Apple „coś knuje"...

Wiesz, niedawno rozmawiałem ze znajomym (użytkownik iPad'a) na temat telewizora Apple. On stwierdził, że taki telewizor powinien mieć wbudowaną konsole do gier. Ja mu odpowiedziałem - Po co? Konsolę masz w ręce!!!
Właśnie. Jak widzę niektóre gry na iOS, to konsole nie mają się czym specjalnie szczycić. A teraz jeszcze 64 bit...

iOS jest obecnie niezła platformą do grania i dosyć bogatą w tytuły. Ekosystem Apple umożliwia zarazem wykorzystanie iPhone'a jako konsoli czy kontrolera w zależności od potrzeb.
A teraz będzie jeszcze fajniej. Może sam napisze jakąś gierkę z użyciem nowego SpriteKit w iOS 7 i potem szybko ja przeportuję na OS 10.9.

A co z programami użytkowymi? Office już niby jest, bo Microsoft raczej ucieka w chmurę. Ale Photoshop, Ilustrator i inne programy... Ja to załatwić na ARM?
Jak Intel dał radę emulować PowerPC (Intel ma dużo gorszą architekturę niż PowerPC i ARM pod względem bałaganu i zaszłości) to i ARM sobie na początku poradzi. Adobe trochę zwlekał podczas przesiadki z PowerPC na Intela ale potem i tak musiał się dostosować. Tak samo może być z ARM, nie przestawią się? Wypadną z rynku. Kluczowa jest kwestia przyzwoitej emulacji Intel na ARM w okresie przejściowym.

Jeszcze jakbyś mógł wyjaśnić krótko n czym polega bałagan w Intelu takim laikom jak ja...
Łatwiej jest wyjaśnić na czym polega porządek... W procesorach PowerPC i ARM jest pewna ilość identycznych rejestrów do przechowywania danych ogólnego przeznaczenia oraz kilka rejestrów specjalnych. W Intelu jest wiele rejestrów specyficznego zastosowania co wymuszone jest koniecznością zapewnienia zgodności z architekturą z przed 30-lat. PowerPC i ARM powstały znacznie później i w oparciu o inne założenia. Przez ten czas (od debiutu Intela) ludzie projektujący procesory wiele się nauczyli. Kolejna rzecz to lista instrukcji. Tu też mamy ład w PowerPC i ARM i ogromny bałagan w Intelu.

Z tego co wiem, ARM i PowerPC maja mniej instrukcji niż Intel?
ARM w zasadzie tak, PowerPC ma mniej ale niewiele mniej. ARM ma za to jedną fajną cechę - brak instrukcji skoków warunkowych takich, które po sprawdzeniu warunku i np. jak jest on spełniony to przeskakują gdzieś w inne miejsce kodzie. Mają to zrobione rewelacyjnie, bo każda instrukcja ma flagi (znaczniki) gdzie się ustawia w jakich warunkach ma się ona wykonać. Czyli najpierw np. porównuje się wartości dwóch rejestrów (co ustawia odpowiednie flagi), potem w zależności od ustawionych flag kolejna instrukcja wykonuje się lub nie. To bardzo ułatwia optymalizację kodu i umożliwia jednoczesne wykonywanie wielu instrukcji i zmniejsza straty przy skokach. Zresztą sam wiesz jak już niewiele ARM 64-bit ustępuje wydajnością Intelowi ze znacznie szybszym taktowaniem. Zawdzięcza to między innymi optymalizacji kodu i sporej ilości identycznych rejestrów.

A do tego dochodzi jeszcze mniejszy apetyt na energię. Przypuszczam, że zastosowanie nawet dwóch procesorów A7 byłoby i tak mniej prądożerne niż jeden Intel.
Nawet zastosowanie czterech, albo osiem rdzeni ARM zamiast 2 Intela.

Teoretycznie dwa lub trzy procesory A7, nawet uwzględniając fakt, że ich równoległa praca nie jest sumą ich wydajności, byłaby porównywalna z tym co ma obecnie MacBook Air. (Procesor A7 osiąga wynik Geekbench 2559 punktów. Zastosowanie dwóch takich procesorów, na pewno nie da wyniku 2*2559, tylko nieco mniej).
Tak, zwłaszcza w OS X czy iOS i programach napisanych w Objective-C. Apple dzięki Objective-C bardzo ułatwia programowanie na wielordzeniowe, wielowątkowe procesory. W zasadzie programista niewiele musi myśleć o tym. Po prostu jak używa on kilku objektów, to działają one samodzielnie i to ułatwia rozdzielanie przez system obciążenia na kilka rdzeni. A już jak świadomie używa się wątków, to wydajność przy wielu rdzeniach znacznie wzrasta.

Czyli zmiana na kolejne Ax miałaby wymierny zysk i niewiele wad?
Tak. I jeszcze jedna zaleta. Apple uniezależniłby się od projektantów procesorów. Teraz musi liczyć na to, co zrobi Intel. A jak Intel zrobi nowy procesor to Apple, Acer, HP i każdy inny producent komputerów też będzie go zaraz miał. A tak Apple samo sobie będzie mogło projektować i procesory i system, a co najważniejsze, zrobią to optymalnie.

To prawda. Czyli laptop na Ax, a może tablet wsuwany jak niegdyś PowerBook Duo w stację dokującą?
Nie! Żadnych półśrodków. Albo tablet albo komputer

Jeszcze kwestia grafiki. Czy iPad ma oddzielny układ graficzny czy to wszystko jest w Ax?
Wszytko mieści się w układzie Ax Apple. Oddzielnie jest tylko pamięć RAM (w układach dla iPad’a, w iPhone RAM jest wbudowany).

A jak taki zestaw sprawdzałby się w MacBooku Air? Pytam tylko o grafikę.
Jak daje radę z rozdzielczościami 2500x1500 (iPad Retina) to z 1440x900 nie da sobie rady? Intel też stosuje wbudowane w procesor układy graficzne.

Ale dochodzi jeszcze masa innych rzecz, np. grafika 3D.
Infinity Blade III? Pamiętaj, Apple sam projektuje te procesory i daje im grafikę jaką chce. Nie używa Targi czy czegoś tam od zewnętrznych producentów jak konkurencja. Obecnie używa rdzeni graficznych PowerVR od Imagination Technologies i Apple ma udziały w tej firmie.

Wróćmy w takim razie do jednego problemu jaki nam ciągle pozostał. Emulacja Intela. Jak widzisz sposób na rozwiązanie tego problemu? Jak to wyglądało gdy PowerPC emulował Motorolę, a jak gdy Intel udawał PowerPC?
Intel jak na swój "bałagan" całkiem nieźle radził sobie z emulacja PowerPC. W 2004 roku Apple kupiło jedną czy dwie firmy zajmujące się prekompilacją i emulacją miedzyplatformową. Rosetta (emulator PowerPC na Intelu zaszyty w Mac OS X) była bardzo wydajna bo stosowała technikę prekompilacji i zapamiętywał przekompilowany już kod. Dlatego program PowerPC pierwszy raz na Intelu uruchamiał się wolniej, ale później już działał szybciej. Ta samą technologie można zastosować podczas emulacji Intela na procesorze ARM.

No tyle, że wówczas procesor emulujący był dużo szybszy niż ten emulowany. Teraz nie ma takiej różnicy patrząc po wynikach Geekbench.
Zaraz, zaraz... Ale mówisz o A7 z iPhone'a a nie o np. A8 z MacBooka Air... Może Apple zrobi taktowanie 2 GHz a nie 1.3 GHz i zamiast dwóch, da cztery rdzenie. I co wtedy?

To prawda Jaromir, dziękuję z rozmowę i na koniec pytanie. Chciałbyś MacBooka na ARM?
Tak, ja bym chciał, i iMac’a i inne też. Po prostu nie lubię Intela…