První Mac s procesorem ARM: navzdory NDA unikly fotky a testy, slušný výkon x86 emulace

39

První Mac s procesorem ARM už se dostal k vývojářům. Apple ho jen půjčuje, nesmí se rozebrat a benchmarky jsou zakázané, ale něco o výkonu přece jenom prosáklo.

Minulý týden Apple s velkou slávou potvrdil přechod počítačů s MacOS na procesory vlastní výroby s instrukční sadou ARM. Zatímco operační systém firma překlopí na novou architekturu sama, množství softwaru od externích vývojářů se samo nepřepíše a proto pro přípravu Apple vyrobil pilotní hardware – Mac Mini poháněný procesorem Apple A12Z z aktuálního iPadu Pro.

Tato zajímavá mašinka nazvaná Developer Transition Kit se bohužel nebude volně prodávat – dokonce by zřejmě měla být jen půjčená a Apple ji bude chtít za jeden rok zpět (ačkoli za připuštění stejně musíte zaplatit 500 $).

Stroj se už začal dostávat k vývojářům, kteří se dostali do programu Applu, takže se můžeme podívat na fotky a specifikace. Zápůjčka je bohužel pod NDA, které zakazuje publikování benchmarků nebo i rozmontování šasi (i jakékoli focení či natáčení, bez dovolení nesmíte počítač ani nakreslit nebo popisovat svoje dojmy), ale našli se odvážlivci, kteří nějaká výkonnostní čísla prozradili, takže máme i první nástřel toho, jak dobře by ARM Macy mohly běhat.

Apple Developer Transition Kit pro přechod na ARM

Vývojářský kit je mini-desktopek (ovšem třeba oproti NUCům má napájecí zdroj uvnitř) o rozměru 19,7 × 19,7 × 3,6 cm. Jak už bylo řečeno, není bohužel vidět dovnitř, takže nevíme, zda je tam procesor A12Z v úplně klasické tabletové podobě. Mohl by teoreticky mít například jinak provedenou operační paměť – ta totiž skýtá na poměry zařízení s iOS štědrou kapacitu 16 GB. Také by bylo pěkné vidět, zda jsou případně použité nějaké přídavné řadiče či rozbočovače PCIe (pro instalované 512GB SSD) a USB.

Apple Developer Transition Kit s procesorem A12Z
Apple Developer Transition Kit s procesorem A12Z (Zdroj: Hexus)

Počítač má klasický gigabitový Ethernet (RJ-45) pro připojení k síti (ale použít lze i interní Wi-Fi 5) a HDMI 2.0 pro připojení monitoru. Zařízení vyvádí čtyři porty USB – dvě klasická velká áčka a dvojí USB-C. Ta nepodporují Thunderbolt 3, jde čistě o USB.

Bude jinak zajímavé vidět, jak Apple Thunderbolt 3 vyřeší. Firma by mohla prostě přeskočit na standardizované USB4 a místo řadičů Intelu implementovat vlastní. Ale pak by možná nemusely na nových počítačích fungovat původní periférie. Na druhou stranu, to už se stalo při přechodu mezi Thunderboltem 2 a nekompatibilním Thunderboltem 3 a Apple si z toho těžkou hlavu nedělal.

Apple Developer Transition Kit s procesorem A12Z iDownload Blog
Apple Developer Transition Kit s procesorem A12Z (Zdroj: iDownload Blog)

Aktivní či pasivní chlazení?

Není bohužel známo, jaké má procesor TDP, ba ani zda je Developer Transition Kit aktivně chlazený. Šasi Mac Mini s počítá s chladičem notebookového stylu s radiálním ventilátorem a na fotkách je vidět podlouhlý výdech chlazení (pod porty). Ale zda je zevnitř slyšet ventilátor nebo cítit vyfukování vzduchu, kupodivu nikdo neuvádí (že by to bylo explicitně zakázané v NDA?). Ostatně i samo publikování fotek a videí na Twitteru zdá se Apple potlačuje.

Měření výkonu (respektive publikování) mají dočasní držitelé těchto zařízení sice zapovězené, ale vypadá to, že někteří hněv Applu riskovali, a únik výkonu se objevil. Neznámí vývojáři nahráli výsledek pro Desktop Transition kit do databáze benchmarku Geekbench.

Podle těchto záznamů má v tomto zařízení procesor A12Z frekvenci 2,4–2,5 GHz (pokud detekce funguje správně). Přímo výpis uvádí sice jen 2,40 GHz, ale podle metadat CPU běželo během testů na taktu okolo 2470 až 2480 MHz, tedy trošku výš. Toto by možná mohlo být turbo. Zajímavé je, že Geekbench ukazuje jenom čtyři vlákna/jádra, jako by systém měl zapnutá jen velká jádra Vortex a ne malá jádra Tempest. Normálně je SoC Apple A12Z 4+4 big-little osmijádro.

Prezentace k přechodu počítačů Apple Mac z procesorů Intel na ARM Zdroj AnandTech 21
Specifikace vývojářského kitu v prezentaci z WWDC (Zdroj: AnandTech)

 

Skóre v Geekbench není na emulaci špatné

V Geekbench 5.2 na MacOS 11 měl systém skóre 833 bodů v jednovláknovém a 2582 ve vícevláknovém testu. Pro srovnání, Core Intel i9-9900K pod MacOS dosahuje až 1400 bodů jednojádrově a 9500 bodů vícevláknově (podle toho, který výsledek berete, Geekbench bohužel má dost velký rozptyl).

Benchmark Developer Transition Kitu v Geekbench 5 Steve Troughton Smith
Benchmark Developer Transition Kitu v Geekbench 5 (Zdroj: Steve Troughton-Smith/Twitter)

V Geekbench 4.4.1 pak zřejmě také tento pilotní ARM Mac dosáhl 3879 bodů jednojádrově a 11 384 bodů vícevláknově. Pokud to opět srovnáme s Core i9-9900K pod MacOS, naleznete výsledky dosahující 6050 až 6500 bodů jednovláknově a 34 000 až 38 000 bodů vícevláknově.

Benchmark Developer Transition Kitu v Geekbench 4 Steve Troughton Smith
Benchmark Developer Transition Kitu v Geekbench 4 (Zdroj: Pierre Dandumont (Twitter))

Na první pohled je tedy A12Z o dost pomalejší, ale ve skutečnosti je to výsledek dost slušný, protože Geekbench běžel v emulaci – spuštěná byla x86-64 verze pro MacOS v překladu přes vrstvu Rosetta 2. Pak je jasné, že musí nastat nějaký propad výkonu. A při zvážení, že frekvence procesoru od Applu byla jen 2,5 GHz, byl vlastně předveden dost pěkný výkon. Nativně dosahuje A12Z ve verzi Geekbench 5 pro iOS (což není asi plně srovnatelné) vyššího skóre – výsledek zde pod emulací je údajně asi o 25 % horší.

Galerie: Apple Developer Transition Kit s procesorem A12Z, fotky, testy výkonu

Pokud by cena emulace byla jen 25 % výkonu proti nativnímu kódu, byl by překlad vlastně velmi efektivní. Ovšem nevíme, zda je to tak jednoduché. Geekbench by totiž pro některé operace snad totiž měl používat knihovny přítomné na počítači, takže ač jde o x86 program, může část úloh ve skutečnosti běžet nativně díky těmto externím knihovnám. Kromě toho také bývají mezi platformami rozdíly ve výkonu (právě kvůli rozdílným externím knihovnám, ale i dalším věcem), což do srovnání vnáší další nepřesnost.

Benchmarky Developer Transition Kitu v Geekbench Toms Hardware
Benchmarky Developer Transition Kitu v Geekbench (Zdroj: Tom’s Hardware)

Pamatujte také na to, že v počítačích, které půjdou reálně do prodeje, budou už nasazené novější procesory, dost možná už na 5nm procesu. Výkon by se tedy ještě měl zlepšit. Zatím tato číslo pochopitelně berte s rezervou, protože není ověřeno, zda třeba nejsou něčím uměle zpomalená (debugovací symboly zakompilované v kódu) a je to jen jeden benchmark, jenž není příliš výpočetně náročný.

Zdroje: Steve Troughton-Smith (Twitter), Pierre Dandumont (Twitter), Hexus, Geekbench, Tom’s Hardware

První Mac s procesorem ARM: navzdory NDA unikly fotky a testy, slušný výkon x86 emulace
Ohodnoťte tento článek!
2.9 (58.67%) 15 hlas/ů

39 KOMENTÁŘE

  1. Vykon Rosety2 je zajimavy. Udajne dochazi k prekompilovani ‚x86‘ kodu v dobe instalace programu, takze v dobe spusteni se uz nacita ARM binarka a nedochazi k on the fly prekladu.
    Na emulaci neni ten vykon spatny, ale delat v tom neco narocnejsiho bych stejne nechtel :))

    • Žádná emulace není na něco náročnějšího. Já jsem hodně zvědavý na nativní výkon, vzhledem ke custom designu by tam Apple mohl narvat HW akceleraci všeho možného, hodila by se akcelerace JS, ono stačí zascrollovat na FB pár stránek a Core i5 se zapotí.

  2. Podle mě je zásadní faktor zvolený test, který procesor nijak zásadně nedrtí, a spíše využívá testy I/O a pokud už něco počítá, tak s podporou API (OGL, Vulcan apod.), takže emulace v tomto ohledu moc roli nehraje.

    Nicméně výsledky ukazují, že minimálně střední třída Maců, určená do běžné kanceláře, na ARMu běžet může (ale to samo o sobě není žádné novum – iPadPro s klávesnicí takto někteří už dávno používají.) Stále si ale myslím, že na reálnou těžkou zátěž ARM stačit nebude.

            • Pretože je to drahé a energeticky náročné. Kedysi som videl porovnanie encodingu videa na iPade Pro a 15″ macbooku pro. Porovnávali modely z roku 2018 a na iPade Pro to bolo rýchlejšie s menej ako polovičnou cenou.

            • Ne. To je tvuj jednostranny pohled. Existuji kvalitativni rozdily pri pouziti SW a HW enkodingu. To ze tobe se zda, ze vyhovuje jeden zpusob neznamena, ze vyhovuje vsem.
              Pokud mas subjektivni problem s enkodingem, muzes si za nej dosadit neco jineho. Treba nekolik virtualnich stroju pro testovani, importy dat, matematicke vypocty, atd.

            • tombomino: kdo by tohle na macbooku dělal? Vždyť to jsou hračky na prezentace a pár grafů nebo tabulek.

            • blue.sun: Řeč je o všech Apple počítačích, ne jenom o macbooku.

            • Kvalitatívne rozdiely medzi hw a sw enkodingom môžu byť pri nejakých bezplatných implementáciach, kde niekto skúša použiť CUDA alebo OpenCL, ale pochybujem, že by sa našli v implementácii od Applu.
              Virtuálne stroje potrebujú dostatok RAM, nie hrubý výkon procesora. Import dát potrebuje rýchlu sieťovku a disk. Aj mac mini sa dá kúpiť s 10Gb sieťovkou a diskom so zápisom okolo 3GB za sekundu. A na matematické výpočty je lepší koprocesor, ktorý si Apple upraví ako chce, ak ho potrebuje.

            • „Kvalitatívne rozdiely medzi hw a sw enkodingom môžu byť pri nejakých bezplatných implementáciach“

              To teda nesouhlasím.
              Ten rozdíl tam je (velký) a principiálně pramení z toho, že hardwarový enkodér (ASIC) zdaleka není tak pružný a nemá tak velké schopnosti udělat nejoptimálnější rozhodnutí mezi jednotlivými kandidáty predikcí/pohybových vektorů, kvantizérů, sílami loopfilteru a tak dál, jako to dokáže software.
              S tím souvisí i že tam bývá horší (pokud vůbec nějaká) úroveň psychovizuálních optimalizací.

              Řekl bych, že tohle je fundamentální faktor, který se nebude dát překonat. Samozřejmě že může existovat mizerný SW enkodér, který prohraje s dobrým HW enkodérem. Je klidně možné, že nějaká profi aplikace bude mít mizerný sw enkodér v sobě. Ale když se srovná state of the art versus state of the art, tak softwarové enkódování bude prostě mít výhodu.

            • „Kvalitatívne rozdiely medzi hw a sw enkodingom môžu byť pri nejakých bezplatných implementáciach“
              .. tohle je principielne hloupost co jste napsal. V cem by jako ta „bezplatna“ implementace mela byt horsi? To jako ze na ni pracuji horsi programatori a apple zamestnava jen vykvet? 🙂 Krome toho OpenCL nebo CUDA vubec nepotrebujete pro SW encoding. Doporucuji, aby jste si veci napred trochu osahal, nez o nich zacnete mluvit.
              „Virtuálne stroje potrebujú dostatok RAM, nie hrubý výkon procesora.“
              .. tohle je dalsi hloupost. Potrebujete oboji a zavisi to od typu ulohy, kterou budete mit. Zadne obecne zavery se z toho nedeaji delat.
              „Aj mac mini sa dá kúpiť s 10Gb“
              .. naopak pro lokalne spustene virtualky, pokud se nebavime o serverech, zadne 10gb sitovky nepotrebuji.
              “ A na matematické výpočty je lepší koprocesor, ktorý si Apple upraví ako chce, ak ho potrebuje.“
              .. Jak muzete mluvit o koprocesoru, kdyz nevite, jaky typ matematicke ulohy budete zpracovavat. Nebo on snad existuje „koporocesor“, ktery zpracova vsechny typu matematickych uloh? Nerika se mu nahodou obecne CPU? 🙂

            • Jan Olšan: Ja porovnávam hw encoder pre HEVC v A12Z procesore so sw encoderom v iPadOS ak procesor nemá hw encoder pre HEVC. Tie sú rovnako kvalitné. Na encoding HEVC videa Apple naozaj nepotrebuje vysoký hrubý výkon procesora.

            • V čom je horší hw encoder pre HEVC v Z12Z procesore oproti sw encoderu v iPadOS?

              Už vidím, ako niekto spúšťa viacero virtuálnych strojov a v každom niečo náročné na procesor aby niečo testoval. Taký test by nedával žiaden zmysel.
              10Gb sieťovka je dobrá na import dát.
              Výhoda vlastného procesora je v tom, že si môže vytvoriť aj vlastný matematický koprocesor presne na tie matematické úlohy, ktoré tam budú bežať.

            • „V čom je horší hw encoder pre HEVC v Z12Z procesore oproti sw encoderu v iPadOS?“
              .. ja nevim, ja iPadOS nepouzivam. Nicmene bavime se obecne a v obecne rovine vase tvzeni neplati. Vemte si Adobe Premieru pro MacOS, ta pouziva jak HW, tak SW encoding. Krome toho, existuji dalis nastroje a programy, takze Vase tvrzeni o tom, ze HW enkoder je stejne dobry jako SW je zalozen na cem? Na jednom programu IpadOS? A neni to trosku malo? :))

              „Už vidím, ako niekto spúšťa viacero virtuálnych strojov a v každom niečo náročné na procesor aby niečo testoval“
              .. Muzete videt co chcete, to nedela Vase tvrzeni opet pravdive. Existuje bezpocet moznosti, jak vyuzivat virtualni stroje lokalne a Vy si tvrdite, ze nepotrebuji vykon? Kde jste na to prisel, vy jste prosel vsechny mozne scenare nasazeni, ze neco takoveho muzete tvrdit?

              „10Gb sieťovka je dobrá na import dát.“
              .. a co kdyz mam ty data lokalne, to by neslo? A jak vite, ze nebudou bottleneckem importu treba vykon CPU? Opet vy znate vsechny mozne scenare pro importovani dat, ze si neco takoveho dovolite tvrdit? :))

              „Výhoda vlastného procesora je v tom, že si môže vytvoriť aj vlastný matematický koprocesor presne na tie matematické úlohy, ktoré tam budú bežať.“
              .. opet.. vy si vymyslite nejaky svuj idealni priklad a delate na nem zavery. Ukazte mi ten „koprocesor“ ktery zpracovava vsechny ty „matematicke“ ulohy, aby jste nejak mohl dokazat, ze to CPU k tomu nepotrebujete?

            • Hmm, no je pravda že totálně netuším, jaký má apple SW enkodér. Můžou mít něco licencovaného (x265 se dá licencovat pro komerční closed-source použití), ale spíš to asi může být vlastního, a pak pochybuju, že to bude špičková implementace. Třeba softwarové H.264 v Quicktime blahé paměti (2005-2010) bylo notoricky mizerné. A tehdy to byl jediný enkodér v systému, kdežto teď je ten software nejspíš jenom nouzovka/fallback.

              To, že se to srovnává jenom s nizoučkou laťkou, ale neznamená, že ten hardware pořád nebude horší než dobrý SW enkodér.

              Jinak teda ještě na okraj – OpenCL nebo CUDA nejsou hardwarové enkodéry, je to spíš GPGPU software pro GPU. Který teda většinou hodně trpí omezeními architektury, proto to vymřelo – tyhle GPGPU aplikace nebyly konkurenceschopné ani s čistým softwarem pro CPU, ani s hardwarem (ASIC).

          • Protože to je nejkvalitnější způsob převodu. Náš grafik to třeba tak dělá, i když má nabušenýho Maca.

            BlueSun: jenže ony nejsou jen Macbooky, existují i drahé 5K all-in-one a pracovní stanice, kde si prostě ARM představit moc nedokážu.

            • Já si nedovedu představit ARM ani v těch macboocích, ale když chce Apple do řiti, umeťme mu cestu.

            • No tak na ten heavy-lifting budeš mít multiXeon mašinu v racku,kterou z iPadu zaúkoluješ.

            • MasoxCZ: jo, to jsou takový ty naivní představy.
              koupíš předraženýho macka s ARMem a zjistíš, že je to lemra. Tak za další balík pořídíš výpočetní stroj do racku, nebo rovnou celý grid. Pak zjistíš, že to brzdí síť a začneš zařizovat 10G switch pro grid a tvého macka. A nakonec zjistíš, že ten macek ani nemá kam ten 10G adaptér připojit, tak to celé poleješ benzinem a zapálíš a jdeš koupit normálního iMac Pro nebo Mac Pro za půl melounu, protože se to nakonec ukáže jako nejlevnější řešení. 🙂

    • „Stále si ale myslím, že na reálnou těžkou zátěž ARM stačit nebude.“

      Proč? Pokud instrukční sada není nějak špatně navržená (a ARMv8 je dobře vyvážená instrukční sada), tak není problém na ní založit výkonné jádro, hlavní je jenom návrh toho jádra, tzv. mikroarchitektura, ne instrukční sada.

      To je jako bychom tvrdili, že angličtina proti němčině (nebo obráceně) se nehodí například na uměleckou literaturu, filozofii nebo na vědecké statě.

      • jenže architektura souvisí s instrukční sadou – ať chceš či ne, musíš funkci dané instrukce nějak promítnout do křemíku – registry počínaje, a vlastním ALU konče. To je přece klidně i příklad AMD vs AVX, kdy implementováno sice měli, ale naprosto neoptimálně a dorovnali to až s Ryzenem.

        A tady je IMHO kámen úrazu. ARM umí navrhovat malá RISCová jádra pro mobily a tablety, ale velké CPU jsou prostě pořád ještě o něčem jiném. Tím neříkám, že se nehodí do desktopů, protože běžný desktop ani dnes věci typu AVX nepotřebuje. Avšak kreslí se tím poměrně jasná a tlustá čára. PC, když to tak vezmu kolem a kolem (pokud si odmyslím stupidní segmentaci Intelu u Pentií a Celerů), bude fungovat od toho „nejblbějšího“ i3 po nabušený Ryzen9/TR/EPYCa – stačí si vybrat výkon. U ARMu se budeš muset vždy nejprve kouknkout, co je to přesně za příchuť a pak ještě zkoumat, kolik křemíku bylo obětováno na implementaci a kolik je toho (potenciálně) řešeno mikrokódem, protože toto dříve či později nastane – odříznout se od ARMv7 jako to udělala v8, nebude tak docela možné, stejně jako nebude možné mít tři platformy podle typu použití. Arm se prostě dnes chová jako Nokia s Microsoftem – uvedli WP7, pak WP8 a nakonec Win10Mobile a tyhle verze, ač byly evolucí, nebyly zpětně kompatibilní, a to ani vůči aplikacím z desktopu. Výhoda „nové“ platformy byla zároveň i její největší nevýhodou.

        • Pekne popsano. Ted uz je jen otazka, nakolik si Apple udela svoje CPU “ASICoidni”, nebo naopak jak moc rozsiri instrukcni sadu v univerzalnejsi rovine. Ja jsem prave zvedavy na ty aplikace popsane vyse, ktere budou potrebovat hruby vykon, jak si tam Apple arm povede.

  3. Naivně jsem si myslel, že Apple přeloží svoje aplikace do ARMu. S tou emulací mi tedy vyrazili dech. Předpokládal jsem, budou postupovat standardní cestou. Asi na rekompilaci nemají sílu a proto postupuji tuhle nesystémovou a nešťastnou cestu.
    I když je brzy něco hodnotit i tak si myslím, že obětovat čtvrtinu výkonu jenom protože použijí jiný procesor aby se zbavili spatné pověsti Intelu to je hodně nerozumné. Touhle koncepcí prakticky vytvářejí nový standard vývoje tedy x86 kód aby byl kompatibilní s Apple ARM emulátorem. Navíc se odstraňování chyb a nekompatibilit také nevyhnou. Jsem opravdu zvědavý jak tohle nakonec dopadne. Přece jenom v budoucnu může vše vypadat jinak.