Ilyen az első 64 bites ARM processzor

Az Apple hagyományosan roppant konzervatív a termékeiben használt hardver specifikációit illetően. Az iPhone 5S múlt heti bejelentésén a gyártó még azt sem közölte, hogy egyáltalán hány maggal rendelkezik az új okostelefon rendszerlapkája (SoC), a marketingeseményen csupán a 64 bites architektúra, a több mint egymilliárd tranzisztor és a jelentős, az elődhöz képest mintegy kétszeres gyorsulás szerepelt az adatok között.

Két mag

Sejtésünk szerint azonban az Apple nem akar teljesen elfordulni a hardveres ínyencségek iránt rajongó felhasználóktól, ezért az iPhone-t tesztelő médiumok (idén igen rövidre szabott) listájára felvette az Anandtech-et is, és félhivatalosan az újság rendelkezésére bocsáthatott exkluzív belső információkat és fejlesztői eszközöket is. A lap élt is a lehetőséggel és igen részletes bemutatót közölt az új iPhone lelkét jelentő Apple A7 SoC-ről, ebből szemezgettünk.

Rögtön az első és talán a legegyszerűbben hozzáférhető információ: az Apple A7 maradt a kétmagos felépítésnél. A gyártó valószínűleg alaposan megfontolta a négymagos kialakítást is, a mobilos számítási feladatok hatékony elvégzéséhez azonban jelenleg két, viszonylag magas teljesítményű mag optimálisabb megoldás, mint négy, alacsonyabb órajelen futó mag használata. A marketinges szempontok az androidos világban felülírják ezt a műszaki tényt, de ahogy a négymagos asztali processzorok hajnalán, a kettőnél több mag használata jelenleg indokolatlan. Az A7 rendszerchip immár a Samsung 28 nanométeres HKMG technológiáján készül, az előző generáció még 32 nanométert használt.

Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

Az x86-os világban az áttörést a Turbo Boost és hasonló technológiák hoztak, amelyek alkalmazásával a fogyasztás dinamikusan szétosztható volt a processzormagok között, egy vagy két mag terhelése esetén azok a névlegesnél jóval magasabb órajelet is elérhettek, így már versenyképesek voltak a magasabb névleges órajelen futó, egy és kétmagos processzorokkal. A több magért többet is kell fizetni, de egy- és kétszálú végrehajtásban már nem visszalépés a több mag. A Turbo Boosthoz hasonló megoldások még nem érhetőek el az ARM-os világban, ezek bevezetése azonban csupán idő kérdése.

Swift után Cyclone

A tavaly bemutatott iPhone 5 volt az Apple első olyan okostelefonja, amely teljes egészében a gyártó által tervezett processzormagokra épült. Az Apple A6 SoC két Swift kódnevű ARM magot használt, amelyeket a cég nem az ARM-tól licencelt, hanem saját mérnökeivel terveztette. Az ARM-világban még a Qualcomm jár hasonló úton, Scorpion és Krait kódnevű magjaival rendre az ARM által kínált Cortexek előtt jár teljesítményben.

A Cyclone legnagyobb újdonsága a 64 bites ARMv8 utasításkészlet támogatása, de emellett számos ponton változott a CPU. A mag maradt out-of-order rendszerű, szélessége azonban kettőről három utasításra nőtt. Az elsőszintű gyorsítótárak mérete 32/32 kilobájtról 64/64 kilobájtra hízott (utasítás és adat). A másodszintű gyorsítótár mérete maradt 1 megabájt, késleltetése azonban felére csökkent az előző generációs Swifthez képest. Generációváltáson esett át a memóriavezérlő, az előtöltő modul és az ágazásbecslő is, a memória sávszélessége például ideális esetben 57 százalékkal magasabb. Az Anandtech kérdésére az Apple megerősítette, hogy az A7 továbbra is 64 bites memóriainterfészt használ, azonban már LPDDR3 szabvánnyal, így a memória valamivel magasabb effektív órajelen működik.

Vadonatúj utasításkészlet

A 32 bites processzorok memóriakorlátjaa a legfontosabb érv a 64 bites architektúra bevezetésére. Míg az ARMv7 architektúrát használó processzorok maximum 4 gigabájt memóriát képesek címezni, ezt a korlátot a 64 bitre váltás olyan szintre tolja ki, amelyet belátható időn belül nem ér el a mobil számítástechnika. A 32 bites ARMv7 ISA-ról ARMv8-ra váltás azonban nem csak egy egyszerű 64 bites kiterjesztést jelent, a két architektúra között radikális eltérések vannak, amelyek némileg növelik az implementáció komplexitását, azonban javítják a kódfuttatás hatékonyságát és érezhető teljesítménynövekedést is hoznak. Az ARMv8 megírásánál az angol vállalat számos évtizedes koncepcióval szakított, az eredmény egy előremutató, letisztult utasításkészlet, modern megoldásokkal.

Az ARMv8 két architekturális állapotot használ, ez az AArch32 és az AArch64. A processzormag készítője dönthet úgy, hogy ebből csak egyiket implementálja, ezzel némi megtakarítás érhető el (néhány 32-bit specifikus áramkör elhagyható). Várhatóan a szerverekbe szánt 64 bites lapkák esetében lesz ez a helyzet, ahol a visszafelé kompatibilitás elhanyagolható tényező. Az Apple azonban mindkét állapotot implementálja, így az A7 probléma nélkül képes futtatni az összes, az App Store-ban található (32 bites) alkalmazást.

ARMv8 hardver

Az ARMv8 implementációja hardveres változásokat is diktál, az ARM specifikációja szerint 16-ról 32-re nő az általános regiszterek száma, amelyek ráadásul 64 bit hosszúak lehetnek. Az Anandtech szerint ez az egyetlen lépés látványos, mintegy 10 százalékos teljesítménynövekedést hoz, ahogy a regisztereken lévő nyomás csökken. Az ARMv8-ban a lebegőpontos és NEON regiszterek száma is duplázódik, szélességük pedig 64 bitről 128 bitre nő, ettől a stream (SIMD) utasítások végrehajtásának sebessége emelkedik.

További változás, hogy megjelentek az AES és SHA1/SHA256 titkosítási algoritmusok hardveres gyorsítását szolgáló kriptográfiai utasítások, az Intel AES-NI utasításaihoz hasonlóan. A titkosítási algoritmusok végrehajtása ennek megfelelően látványosan gyorsult, a szintetikus tesztek szerint az AES mintegy kilencszeres, az SHA1 pedig több, mint háromszoros sebességgel fut - ugyanazon az A7 processzoron, pusztán az alkalmazás újrafordításával.

Az új képességek kiaknázásához értelemszerűen el kell készíteni az app új, 64 bites verzióját, ezt az Apple Xcode fejlesztői környezete és az LLVM fordító már teljes egészében támogatja. Az újrafordítással az alkalmazás már 64 bites futtatókörnyezetet és könyvtárakat használ, amelynek fontos szerepe van a memóriahasználat visszaszorításában.

Indul az átállás

A két utasításarchitektúra egymás mellett élésének ugyanis vannak rövid távú hátrányai, a legfontosabb egyelőre, hogy kétféle futtatókörnyezetre van szükség. A 64 bites rendszeren 64 bites alkalmazások futtatásakor elegendő csak a 64 bites könyvtárakat betölteni a memóriába, egy 32 bites alkalmazás indításakor azonban be kell tölteni a meghívott 32 bites könyvtárakat is. Ez egyrészt komoly I/O-terhelést jelent a betöltés alatt, másrészt a párhuzamos könyvtárak memóriában tartása jelentős memóriahasználatot eredményez. Ezért az Apple igyekszik a fejlesztőket minél előbb rávenni, hogy alkalmazásukból 64 bites verziót is töltsenek fel az App Store-ba, elkerülendő ezt a problémát.

A tesztek szerint az Apple a maga oldalán a házi feladatot teljes mértékben elvégezte. Az iPhone 5S-en futó iOS 7-et az Apple teljes egészében 64 bitre konvertálta, a rendszer minden eleme és a gyári alkalmazások is mind arm64 architektúrát jeleznek ki. Vagyis alapból a 32 bites könyvtárak betöltődése elkerülhető, ha a felhasználó kizárólag 64 bites appokat használ - erre hosszú ideig kell még várni, az átállás azonban az iPhone 5S megjelenésével legalább beindul.

Vadonatúj GPU

Az Apple korábban az Imagination Technologies PowerVR SGX sorozatú grafikus feldolgozóegységeit implementálta rendszerlapkáin, az A7 esetében azonban a gyártó egyszerűen Apple A7 GPU-ként hivatkozik erre az egységre. A támogatott technológiákból azonban viszonylag egyszerűen leszűkíthető a potenciális GPU-k köre, egyedül a PowerVR SGX vadonatúj, 6-os sorozata tud egyszerre OpenGL ES 3.0-t, TBDR-t (tile based deferred rendering) és 8x MSAA élsimítást. Ezzel az Apple A7 nem csak az első 64 bites és ARMv8-as SoC, de az első SGX 6-ot implementáló chip koronáját is megszerzi.

A teljesítménytesztek szerint az új GPU hozza az iPad 4 óriási méretű és magas fogyasztású GPU-jának teljesítményét, ami nem kis előrelépés egy okostelefontól. Az androidos versenytársakhoz képest már vegyes a kép, a "tavaszi" felhozatalhoz (HTC One, SGS4) képest magasabb a teljesítmény, a modernizált Snapdragonokat használó "őszi" telefonok (LG G2) azonban azonos, vagy némileg magasabb nyers teljesítményt nyújtanak, mint az iPhone GPU-ja. Persze érdemes hozzátenni, hogy ezek a GPU-k önmagukban nem vásárolhatóak meg, csak kijelzőhöz párosítva, az iPhone 5S pedig csak 727 ezer pixellel rendelkezik, szemben az androidos csúcsmodellek több mint kétmillió pixelével, így a GPU-nak így harmadannyi képelemet kell meghajtania.

Látványos teljesítménynövekedés

Az előző generációs iPhone-okhoz viszonyítva az iPhone 5S igen meggyőző teljesítményt mutat, részben az új, hatékonyabb ARMv8 utasításkészletnek, részben pedig a fejlettebb processzornak betudhatóan. Azonos böngészőt használva például SunSpider 1.0 alatt 415 ezredmásodperces eredményt ér el az új hardver, szemben az iPhone 5 727 ms-os idejével. Összehasonlításképp a legkorábbi, iOS 7-tel kompatibilis telefon, az iPhone 4 2947 ezredmásodperces időt ér el, az egymagos Cortex-A8 óta ekkora fejlődést mutatnak az okostelefonok rendszerlapkái.

Sajnos megbízható keresztplatformos hardvertesztek nem állnak rendelkezésre, a különböző böngészők használata pedig alapvetően befolyásolja a JavaScript tesztek eredményeit. Műszaki szempontból emiatt az ilyen összehasonlítások nem alkalmasak a mikroarchitektúrák összevetésére, de a felhasználói élményről (paradox módon) kiváló eredményt adnak: a felhasználó ugyanis pontosan ezzel a "szűrt", az operációs rendszer, a fordító, a futtatókörnyezet, a JS-motor által módosított teljesítménnyel találkozik.

Eszerint az Apple A7 hozza a jelenleg elérhető tabletes Intel Bay Trail-generációs Atomjainak szintjét, miközben ez utóbbi fogyasztása ás hőtermelése a megcélzott eszközök (tabletek) miatt valószínűleg számottevően magasabb, mint az okostelefonos A7-nek. CPU-teljesítményben az A7 köröket ver a jelenleg elérhető androidos okostelefonokra, a Galaxy S4 vagy a HTC One fele akkora sebességet ér el SunSpider alatt, mint az Apple (az összevetést értelemszerűen a Chrome vs Safari különbség is módosítja). Ugyanez a sebességkülönbség jelentkezik a Mozilla Kraken és Google Octane JS-tesztek alatt is, a részletes eredményekért érdemes az Anandtech grafikonjait átnézni.