Sulje mainos

Mike Ash omistettu blogissaan iPhone 64S:n 5-bittiseen arkkitehtuuriin siirtymisen käytännön seuraukset. Tämä artikkeli perustuu hänen havaintoihinsa.

Syy tähän tekstiin johtuu pääasiassa siitä, että levitetään paljon väärää tietoa siitä, mitä uusi iPhone 5s 64-bittisellä ARM-prosessorilla todella tarkoittaa käyttäjille ja markkinoille. Täällä yritämme tuoda objektiivista tietoa tämän siirtymän suorituskyvystä, ominaisuuksista ja vaikutuksista kehittäjille.

"64-bittinen"

Prosessorissa on kaksi osaa, joihin "X-bit"-merkintä voi viitata - kokonaislukurekisterien leveys ja osoittimien leveys. Onneksi useimmissa nykyaikaisissa prosessoreissa nämä leveydet ovat samat, joten A7:n tapauksessa tämä tarkoittaa 64-bittisiä kokonaislukurekistereitä ja 64-bittisiä osoittimia.

Yhtä tärkeää on kuitenkin huomauttaa, mitä "64-bittinen" EI tarkoita: RAM-muistin fyysisen osoitteen koko. RAM-muistin kanssa kommunikoivien bittien määrä (eli laitteen tukeman RAM-muistin määrä) ei liity CPU-bittien määrään. ARM-prosessoreilla on missä tahansa 26-40-bittiset osoitteet, ja niitä voidaan muuttaa muusta järjestelmästä riippumatta.

  • Tietoväylän koko. RAM-muistista tai puskurimuistista vastaanotetun tiedon määrä on samoin riippumaton tästä tekijästä. Yksittäiset prosessorin käskyt voivat pyytää eri määriä dataa, mutta ne joko lähetetään paloina tai niitä vastaanotetaan enemmän kuin tarvitaan muistista. Se riippuu datakvantin koosta. IPhone 5 vastaanottaa jo dataa muistista 64-bittisinä kvantteina (ja siinä on 32-bittinen prosessori), ja voimme kohdata jopa 192-bittisiä kokoja.
  • Kaikki mikä liittyy liukulukuihin. Tällaisten rekisterien (FPU) koko on jälleen riippumaton prosessorin sisäisestä toiminnasta. ARM on käyttänyt 64-bittistä FPU:ta ennen ARM64:ää (64-bittinen ARM-prosessori).

Yleiset edut ja haitat

Jos verrataan muuten identtisiä 32- ja 64-bittisiä arkkitehtuureja, ne eivät yleensä eroa toisistaan. Tämä on yksi syy yleisön yleiseen hämmennykseen, joka etsii syytä, miksi Apple siirtyy 64-bittiseen myös mobiililaitteissa. Kaikki johtuu kuitenkin A7 (ARM64) -prosessorin erityisistä parametreista ja siitä, miten Apple käyttää sitä, ei vain siitä, että prosessorissa on 64-bittinen arkkitehtuuri.

Kuitenkin, jos tarkastelemme edelleen näiden kahden arkkitehtuurin välisiä eroja, löydämme useita eroja. Ilmeinen on, että 64-bittiset kokonaislukurekisterit voivat käsitellä 64-bittisiä kokonaislukuja tehokkaammin. Jo aiemmin niiden kanssa oli mahdollista työskennellä 32-bittisillä prosessoreilla, mutta tämä tarkoitti yleensä niiden jakamista 32-bittisiin osiin, mikä hidasti laskelmia. Joten 64-bittinen prosessori voi yleensä laskea 64-bittisillä tyypeillä yhtä nopeasti kuin 32-bittisillä. Tämä tarkoittaa, että sovellukset, jotka käyttävät yleensä 64-bittisiä tyyppejä, voivat toimia paljon nopeammin 64-bittisellä prosessorilla.

Vaikka 64-bittinen ei vaikuta prosessorin käyttämän RAM-muistin kokonaismäärään, se voi helpottaa suurten RAM-osien käsittelyä yhdessä ohjelmassa. Jokaisella 32-bittisellä prosessorilla toimivalla ohjelmalla on vain noin 4 Gt osoitetilaa. Kun otetaan huomioon, että käyttöjärjestelmä ja standardikirjastot vievät jotain, jää ohjelmalle 1-3 Gt sovelluskäyttöön tilaa. Jos 32-bittisessä järjestelmässä on kuitenkin yli 4 Gt RAM-muistia, tämän muistin käyttö on hieman monimutkaisempaa. Meidän on turvauduttava pakottamaan käyttöjärjestelmä kartoittamaan nämä suuremmat muistinpalaset ohjelmallemme (muistin virtualisointi), tai voimme jakaa ohjelman useisiin prosesseihin (jossa jokaisella prosessilla on teoriassa jälleen 4 Gt muistia suoraa osoitetta varten).

Nämä "hakkerointi" ovat kuitenkin niin vaikeita ja hitaita, että minimisovellukset käyttävät niitä. Käytännössä 32-bittisessä prosessorissa kukin ohjelma käyttää vain 1-3 Gt muistiaan, ja enemmän käytettävissä olevaa RAM-muistia voidaan käyttää useiden ohjelmien ajamiseen samanaikaisesti tai käyttää tätä muistia puskurina (välimuistina). Nämä käyttötavat ovat käytännöllisiä, mutta haluaisimme, että kaikki ohjelmat pystyvät helposti käyttämään yli 4 Gt:n muistia.

Nyt tulemme usein toistuvaan (itse asiassa virheelliseen) väitteeseen, että ilman yli 4 Gt muistia 64-bittinen arkkitehtuuri on hyödytön. Suurempi osoitetila on hyödyllinen myös järjestelmässä, jossa on vähemmän muistia. Muistikartoitetut tiedostot ovat kätevä työkalu, jossa osa tiedoston sisällöstä on loogisesti linkitetty prosessin muistiin ilman, että koko tiedostoa tarvitsee ladata muistiin. Siten järjestelmä voi esimerkiksi asteittain käsitellä suuria tiedostoja, jotka ovat monta kertaa suurempia kuin RAM-kapasiteetti. 32-bittisessä järjestelmässä näin suuria tiedostoja ei voida luotettavasti kartoittaa muistia, kun taas 64-bittisessä järjestelmässä se on vain pala kakkua paljon suuremman osoitetilan ansiosta.

Suurempi osoittimien koko tuo kuitenkin mukanaan myös yhden suuren haitan: muuten identtiset ohjelmat tarvitsevat enemmän muistia 64-bittisessä prosessorissa (nämä isommat osoittimet täytyy tallentaa jonnekin). Koska osoittimet ovat yleinen osa ohjelmia, tämä ero voi kuormittaa välimuistia, mikä puolestaan ​​​​hitaa koko järjestelmän toiminnan. Joten perspektiivistä voimme nähdä, että jos vain muuttaisimme prosessorin arkkitehtuurin 64-bittiseksi, se itse asiassa hidastaisi koko järjestelmää. Joten tämä tekijä on tasapainotettava useammilla optimoinnilla muissa paikoissa.

ARM64

Uuden iPhone 7s:n 64-bittinen prosessori A5 ei ole vain tavallinen ARM-prosessori, jolla on laajemmat rekisterit. ARM64 sisältää merkittäviä parannuksia vanhempaan, 32-bittiseen versioon verrattuna.

Apple A7 prosessori.

rekisterin

ARM64 sisältää kaksi kertaa niin monta kokonaislukurekisteriä kuin 32-bittinen ARM (varo sekoittamasta rekisterien määrää ja leveyttä - puhuimme leveydestä "64-bit"-osiossa. Joten ARM64:ssä on sekä kaksi kertaa leveämpiä rekistereitä että kaksi kertaa enemmän rekisterit). 32-bittisessä ARM:ssa on 16 kokonaislukurekisteriä: yksi ohjelmalaskuri (PC - sisältää nykyisen käskyn numeron), pinoosoitin (osoitin meneillään olevaan toimintoon), linkkirekisteri (osoitin lopun jälkeiseen palautukseen toiminnosta), ja loput 13 ovat sovelluskäyttöön. ARM64:ssä on kuitenkin 32 kokonaislukurekisteriä, mukaan lukien yksi nollarekisteri, linkkirekisteri, kehysosoitin (samanlainen kuin pinoosoitin) ja yksi tulevaisuutta varten. Tämä jättää meille 28 rekisteriä sovellusten käyttöön, mikä on yli kaksinkertainen 32-bittiseen ARM:ään verrattuna. Samaan aikaan ARM64 kaksinkertaisti liukulukurekisterien (FPU) määrän 16:sta 32:een 128-bittiseen rekisteriin.

Mutta miksi rekisterien määrä on niin tärkeä? Muisti on yleensä hitaampaa kuin suorittimen laskelmat ja lukeminen/kirjoittaminen voi kestää hyvin kauan. Tämä saisi nopean prosessorin odottamaan muistia ja osuisimme järjestelmän luonnolliseen nopeusrajoitukseen. Prosessorit yrittävät piilottaa tämän haitan puskurikerroksilla, mutta nopeinkin (L1) on silti hitaampi kuin prosessorin laskelma. Rekisterit ovat kuitenkin suoraan prosessorissa olevia muistisoluja ja niiden lukeminen/kirjoittaminen on riittävän nopeaa, jotta ne eivät hidasta prosessoria. Rekistereiden määrä tarkoittaa käytännössä nopeimman muistin määrää prosessorilaskelmille, mikä vaikuttaa suuresti koko järjestelmän nopeuteen.

Samalla tämä nopeus tarvitsee kääntäjän hyvän optimointituen, jotta kieli voi käyttää näitä rekistereitä eikä sen tarvitse tallentaa kaikkea yleissovelluksen (hidas) muistiin.

Käyttöohjeet

ARM64 tuo myös suuria muutoksia ohjesarjaan. Käskyjoukko on joukko atomioperaatioita, joita prosessori voi suorittaa (esim. 'ADD register1 register2' lisää numerot kahteen rekisteriin). Yksittäisten kielten käytettävissä olevat toiminnot koostuvat näistä ohjeista. Monimutkaisempien toimintojen on suoritettava enemmän käskyjä, jotta ne voivat olla hitaampia.

Uutta ARM64:ssä ovat ohjeet AES-salaukseen, SHA-1- ja SHA-256-hajautustoimintoihin. Joten monimutkaisen toteutuksen sijaan vain kieli kutsuu tätä ohjetta - mikä tuo valtavan nopeuden tällaisten toimintojen laskemiseen ja toivottavasti lisää turvallisuutta sovelluksissa. Esim. uusi Touch ID käyttää näitä ohjeita myös salauksessa, mikä mahdollistaa todellisen nopeuden ja turvallisuuden (teoriassa hyökkääjän olisi muokattava itse prosessoria päästäkseen tietoihin - mikä on vähintäänkin epäkäytännöllistä sen pienen koon vuoksi).

Yhteensopivuus 32 bitin kanssa

On tärkeää mainita, että A7 voi toimia täysin 32-bittisessä tilassa ilman emulointia. Se tarkoittaa, että uusi iPhone 5s voi ajaa 32-bittiselle ARM:lle käännettyjä sovelluksia ilman hidastumista. Tällöin se ei kuitenkaan voi käyttää uusia ARM64-toimintoja, joten kannattaa aina tehdä erityinen rakennus vain A7:lle, jonka pitäisi toimia paljon nopeammin.

Käyttöajan muutokset

Runtime on koodi, joka lisää ohjelmointikieleen toimintoja, joita se voi käyttää sovelluksen ollessa käynnissä käännöksen jälkeen. Koska Applen ei tarvitse ylläpitää sovellusten yhteensopivuutta (että 64-bittinen binääri toimii 32-bittisellä), heillä on varaa tehdä vielä muutamia parannuksia Objective-C-kieleen.

Yksi niistä on ns merkitty osoitin (merkitty indikaattori). Normaalisti objektit ja osoittimet näihin objekteihin tallennetaan erillisiin muistin osiin. Uudet osoitintyypit antavat kuitenkin luokat, joilla on vähän tietoa, tallentaa objekteja suoraan osoittimeen. Tämä vaihe poistaa tarpeen varata muistia suoraan objektille, luo vain osoitin ja objekti sen sisällä. Merkittyjä osoittimia tuetaan vain 64-bittisessä arkkitehtuurissa myös siksi, että 32-bittisessä osoittimessa ei ole enää tarpeeksi tilaa tarpeeksi hyödyllisen tiedon tallentamiseen. Siksi iOS, toisin kuin OS X, ei vielä tukenut tätä ominaisuutta. ARM64:n saapuessa tämä kuitenkin muuttuu, ja iOS on saavuttanut OS X:n tässäkin suhteessa.

Vaikka osoittimet ovat 64 bittiä pitkiä, ARM64:ssä käytetään vain 33 bittiä osoittimen omana osoitteena. Ja jos pystymme luotettavasti paljastamaan loput osoitinbitit, voimme käyttää tätä tilaa lisätietojen tallentamiseen - kuten mainittujen merkittyjen osoittimien tapauksessa. Käsitteellisesti tämä on yksi suurimmista muutoksista Objective-C:n historiassa, vaikka se ei olekaan markkinoitava ominaisuus - joten useimmat käyttäjät eivät tiedä, kuinka Apple vie Objective-C:tä eteenpäin.

Mitä tulee hyödyllisiin tietoihin, jotka voidaan tallentaa tällaisen merkityn osoittimen jäljellä olevaan tilaan, esimerkiksi Objective-C käyttää sitä nyt ns. viitemäärä (viitteiden määrä). Aikaisemmin viitemäärä oli tallennettu eri paikkaan muistissa, sitä varten valmisteltuun hash-taulukkoon, mutta tämä saattoi hidastaa koko järjestelmää, jos kutsuja oli suuri määrä alloc/dealloc/retain/release. Taulukko jouduttiin lukitsemaan lankojen turvallisuuden vuoksi, joten kahdessa säikeessä kahden kohteen viitemäärää ei voitu muuttaa samanaikaisesti. Tämä arvo on kuitenkin juuri lisätty muuhun ns ISA indikaattoreita. Tämä on toinen huomaamaton, mutta valtava etu ja kiihtyvyys tulevaisuudessa. Tätä ei kuitenkaan koskaan voitu saavuttaa 32-bittisessä arkkitehtuurissa.

Objektien jäljelle jäävään osoittimien paikkaan lisätään myös uusi tieto siihen liittyvistä objekteista, onko objektiin heikosti viitattu, onko objektille tarpeen luoda tuhoaja jne. Tämän tiedon ansiosta Objective-C runtime pystyy nopeuttamaan suoritusaikaa perusteellisesti, mikä heijastuu kunkin sovelluksen nopeuteen. Testauksen perusteella tämä tarkoittaa noin 40-50 % nopeutta kaikista muistinhallintakutsuista. Vain vaihtamalla 64-bittisiin osoittimiin ja käyttämällä tätä uutta tilaa.

Záver

Vaikka kilpailijat yrittävät levittää ajatusta, että 64-bittiseen arkkitehtuuriin siirtyminen on tarpeetonta, tiedät jo, että tämä on vain hyvin tietämätön mielipide. On totta, että pelkkä 64-bittiseen vaihtaminen ilman kielen tai sovellusten mukauttamista siihen ei tarkoita oikeastaan ​​mitään - se jopa hidastaa koko järjestelmää. Mutta uusi A7 käyttää modernia ARM64:ää uudella ohjesarjalla, ja Apple on vaivannut modernisoidakseen koko Objective-C-kielen ja hyödyntääkseen uusia ominaisuuksia - tästä syystä luvattu nopeus.

Tässä olemme maininneet useita syitä, miksi 64-bittinen arkkitehtuuri on oikea askel eteenpäin. Se on toinen vallankumous "konepellin alla", jonka ansiosta Apple yrittää pysyä eturintamassa paitsi suunnittelun, käyttöliittymän ja rikkaan ekosysteemin, vaan pääasiassa markkinoiden uusimpien teknologioiden avulla.

Lähde: mikeash.com
.