Lokaðu auglýsingu

Mike Ash tileinkað blogginu sínu hagnýtar afleiðingar þess að skipta yfir í 64-bita arkitektúr í iPhone 5S. Þessi grein byggir á niðurstöðum hans.

Ástæðan fyrir þessum texta er aðallega vegna mikillar rangra upplýsinga sem dreift er um hvað nýi iPhone 5s með 64 bita ARM örgjörva þýðir í raun fyrir notendur og markað. Hér munum við reyna að koma með hlutlægar upplýsingar um frammistöðu, getu og afleiðingar þessarar umskiptis fyrir þróunaraðila.

"64 bita"

Það eru tveir hlutar örgjörva sem "X-bit" merkimiðinn getur vísað til - breidd heiltöluskránna og breidd vísanna. Sem betur fer eru þessar breiddir þær sömu á flestum nútíma örgjörvum, þannig að í tilviki A7 þýðir þetta 64-bita heiltöluskrár og 64-bita ábendingar.

Hins vegar er jafn mikilvægt að benda á hvað "64bit" þýðir EKKI: Stærð RAM líkamlegt heimilisfang. Fjöldi bita sem eiga að hafa samskipti við vinnsluminni (þannig hversu mikið vinnsluminni tæki styður) er ekki tengt fjölda örgjörvabita. ARM örgjörvar hafa hvar sem er á milli 26 og 40 bita vistföng og hægt er að breyta þeim óháð restinni af kerfinu.

  • Stærð Gagnarútu. Magn gagna sem berast frá vinnsluminni eða biðminni er á sama hátt óháð þessum þætti. Einstakar leiðbeiningar örgjörva geta beðið um mismikið gagnamagn, en þær eru annað hvort sendar í klumpum eða berast meira úr minni en þörf er á. Það fer eftir stærð gagnaskammta. iPhone 5 tekur nú þegar við gögnum úr minninu í 64 bita magni (og er með 32 bita örgjörva) og við getum rekist á stærðir allt að 192 bita.
  • Allt sem tengist floating point. Stærð slíkra skráa (FPU) er aftur óháð innri starfsemi örgjörvans. ARM hefur notað 64-bita FPU síðan fyrir ARM64 (64-bita ARM örgjörva).

Almennir kostir og gallar

Ef við berum saman annars eins 32bita og 64bita arkitektúr eru þeir almennt ekki svo ólíkir. Þetta er ein af ástæðunum fyrir almennu rugli almennings sem leitar að ástæðu fyrir því að Apple er að fara yfir í 64bit í farsímum líka. Hins vegar kemur þetta allt frá sérstökum breytum A7 (ARM64) örgjörvans og hvernig Apple notar hann, ekki bara frá því að örgjörvinn er með 64 bita arkitektúr.

Hins vegar, ef við lítum enn á muninn á þessum tveimur arkitektúrum, munum við finna nokkurn mun. Það augljósa er að 64 bita heiltöluskrár geta séð um 64 bita heiltölur á skilvirkari hátt. Jafnvel áður var hægt að vinna með þá á 32 bita örgjörvum, en það þýddi venjulega að skipta þeim í 32 bita langa bita sem olli hægari útreikningum. Þannig að 64-bita örgjörvi getur almennt reiknað með 64-bita gerðum alveg jafn hratt og með 32-bita. Þetta þýðir að forrit sem almennt nota 64-bita gerðir geta keyrt miklu hraðar á 64-bita örgjörva.

Þrátt fyrir að 64bit hafi ekki áhrif á heildarmagn vinnsluminni sem örgjörvinn getur notað getur það gert það auðveldara að vinna með stóra vinnsluminni í einu forriti. Sérhvert stakt forrit sem keyrir á 32-bita örgjörva hefur aðeins um 4 GB af vistfangarými. Að teknu tilliti til þess að stýrikerfið og venjuleg bókasöfn taka upp eitthvað, skilur þetta forritið eftir einhvers staðar á bilinu 1-3 GB til notkunar í forritum. Hins vegar, ef 32-bita kerfi er með meira en 4 GB af vinnsluminni, er notkun þess minni aðeins flóknari. Við verðum að grípa til þess ráðs að þvinga stýrikerfið til að kortleggja þessa stærri klumpa af minni fyrir forritið okkar (minni sýndarvæðing), eða við getum skipt forritinu í marga ferla (þar sem hvert ferli hefur aftur fræðilega séð 4 GB af minni tiltækt fyrir bein heimilisfang).

Hins vegar eru þessar "hacks" svo erfiðar og hægar að lágmarks forrit nota þau. Í reynd, á 32-bita örgjörva, mun hvert forrit aðeins nota 1-3 GB af minni, og meira tiltækt vinnsluminni er hægt að nota til að keyra mörg forrit á sama tíma eða nota þetta minni sem biðminni (skyndiminni). Þessi notkun er hagnýt, en við viljum að hvaða forrit sem er geti auðveldlega notað minnishluta sem eru stærri en 4GB.

Nú komum við að þeirri tíðu (reyndar röngu) fullyrðingu að án meira en 4GB af minni sé 64-bita arkitektúr gagnslaus. Stærra heimilisfangrými er gagnlegt jafnvel á kerfi með minna minni. Minniskortaðar skrár eru handhægt tól þar sem hluti af innihaldi skráarinnar er rökrétt tengdur við minni ferlisins án þess að hlaða þurfi allri skránni inn í minnið. Þannig getur kerfið til dæmis smám saman unnið úr stórum skrám sem eru margfalt stærri en vinnsluminni. Í 32-bita kerfi er ekki hægt að kortleggja svo stórar skrár á áreiðanlegan hátt í minni, en á 64-bita kerfi er það stykki af köku, þökk sé miklu stærra vistfangarými.

Hins vegar, stærri stærð ábendinga hefur einnig einn stóran ókost: annars þurfa sams konar forrit meira minni á 64-bita örgjörva (þessar stærri ábendingar verða að vera geymdar einhvers staðar). Þar sem ábendingar eru tíður hluti af forritum getur þessi munur íþyngt skyndiminni, sem aftur veldur því að allt kerfið keyrir hægar. Svo í samhengi getum við séð að ef við breyttum örgjörvaarkitektúrnum í 64-bita myndi það í raun hægja á öllu kerfinu. Þess vegna þarf að jafna þennan þátt með meiri hagræðingu á öðrum stöðum.

ARM64

A7, 64-bita örgjörvinn knýr nýja iPhone 5s, er ekki bara venjulegur ARM örgjörvi með breiðari skrám. ARM64 inniheldur miklar endurbætur á eldri 32-bita útgáfunni.

Apple A7 örgjörvi.

Registry

ARM64 geymir tvöfalt fleiri heiltöluskrár en 32-bita ARM (passið að rugla ekki saman fjölda og breidd skráa - við töluðum um breidd í "64-bita" hlutanum. Þannig að ARM64 hefur bæði tvöfalt breiðari skrár og tvöfalt fleiri skrár). 32-bita ARM hefur 16 heiltöluskrár: einn forritateljara (tölva - inniheldur númer núverandi leiðbeiningar), staflabendill (bendill á aðgerð sem er í gangi), hlekkjaskrá (bendill á skil eftir lok aðgerðarinnar), og hinar 13 eru til notkunar í forritum. Hins vegar hefur ARM64 32 heiltöluskrár, þar á meðal einn núllskrá, hlekkaskrá, rammabendi (svipað og staflabendill) og einn frátekinn fyrir framtíðina. Þetta skilur okkur eftir með 28 skrár til notkunar forrita, meira en tvöfalt 32-bita ARM. Á sama tíma tvöfaldaði ARM64 fjölda floating-point number (FPU) skráa úr 16 í 32 128-bita skrár.

En hvers vegna er fjöldi skráa svo mikilvægur? Minni er yfirleitt hægara en CPU útreikningar og lestur/skrif getur tekið mjög langan tíma. Þetta myndi gera hraðvirki örgjörvann til að halda áfram að bíða eftir minni og við myndum ná náttúrulegum hraðamörkum kerfisins. Örgjörvar reyna að fela þessa fötlun með lögum af biðmunum, en jafnvel sá hraðvirkasti (L1) er samt hægari en útreikningur örgjörvans. Hins vegar eru skrár minnisfrumur beint í örgjörvanum og lestur / ritun þeirra er nógu hröð til að hægja ekki á örgjörvanum. Fjöldi skráa þýðir nánast magn hraðasta minnisins fyrir útreikninga örgjörva, sem hefur mikil áhrif á hraða alls kerfisins.

Á sama tíma þarf þessi hraði góðan hagræðingarstuðning frá þýðandanum svo tungumálið geti notað þessar skrár og þurfi ekki að geyma allt í almennu forritinu (hæga) minni.

Leiðbeiningarsett

ARM64 hefur einnig miklar breytingar á leiðbeiningasettinu. Leiðbeiningarsett er safn atómaðgerða sem örgjörvi getur framkvæmt (td 'ADD register1 register2' bætir við tölunum í tveimur skrám). Aðgerðirnar sem eru tiltækar fyrir einstök tungumál eru samsettar úr þessum leiðbeiningum. Flóknari aðgerðir verða að framkvæma fleiri leiðbeiningar, svo þær geta verið hægari.

Nýtt í ARM64 eru leiðbeiningar fyrir AES dulkóðun, SHA-1 og SHA-256 kjötkássaaðgerðir. Þannig að í stað flókinnar útfærslu mun aðeins tungumálið kalla þessa kennslu - sem mun hraða útreikningi slíkra aðgerða gríðarlega og vonandi auka öryggi í forritum. T.d. nýja Touch ID notar einnig þessar leiðbeiningar í dulkóðun, sem gerir ráð fyrir raunverulegum hraða og öryggi (fræðilega séð, árásarmaður þyrfti að breyta örgjörvanum sjálfum til að fá aðgang að gögnunum - sem er vægast sagt ópraktískt miðað við smærri stærð þeirra).

Samhæfni við 32bit

Það er mikilvægt að nefna að A7 getur keyrt að fullu í 32-bita ham án þess að þörf sé á eftirlíkingu. Það þýðir að nýi iPhone 5s getur keyrt forrit sem eru sett saman á 32-bita ARM án þess að hægja á. Hins vegar getur það ekki notað nýju ARM64 aðgerðirnar, svo það er alltaf þess virði að búa til sérstaka byggingu bara fyrir A7, sem ætti að keyra miklu hraðar.

Breytingar á keyrslutíma

Runtime er kóðinn sem bætir aðgerðum við forritunarmálið, sem það getur notað á meðan forritið er í gangi, þar til eftir þýðingu. Þar sem Apple þarf ekki að viðhalda samhæfni forrita (að 64 bita tvöfaldur keyrir á 32 bita) gætu þeir leyft sér að gera nokkrar endurbætur á Objective-C tungumálinu.

Einn þeirra er svokallaður merktur bendill (merktur vísir). Venjulega eru hlutir og vísar á þá hluti geymdir í aðskildum hlutum minnis. Hins vegar leyfa nýjar benditegundir flokkum með lítil gögn að geyma hluti beint í bendilinn. Þetta skref útilokar þörfina á að úthluta minni beint fyrir hlutinn, búðu bara til bendi og hlutinn inni í honum. Merktir bendilar eru aðeins studdir í 64-bita arkitektúr, einnig vegna þess að það er ekki lengur nóg pláss í 32-bita bendili til að geyma nógu gagnleg gögn. Þess vegna studdi iOS, ólíkt OS X, ekki enn þennan eiginleika. Hins vegar, með tilkomu ARM64, er þetta að breytast og iOS hefur náð OS X í þessu sambandi líka.

Þó að bendillar séu 64 bitar að lengd, eru á ARM64 aðeins 33 bitar notaðir fyrir eigin heimilisfang bendillsins. Og ef við getum afhjúpað afganginn af bendibitunum á áreiðanlegan hátt, getum við notað þetta pláss til að geyma viðbótargögn - eins og í tilviki nefndra merktra bendila. Hugmyndalega er þetta ein stærsta breyting í sögu Objective-C, þó það sé ekki markaðshæfur eiginleiki - svo flestir notendur vita ekki hvernig Apple er að koma Objective-C áfram.

Hvað varðar þau gagnlegu gögn sem hægt er að geyma í því plássi sem eftir er á slíkum merktum bendili, þá notar Objective-C það nú til dæmis til að geyma sk. viðmiðunarfjölda (fjöldi tilvísana). Áður var viðmiðunartalningin geymd á öðrum stað í minni, í kjötkássatöflu sem útbúin var fyrir hana, en það gæti hægt á öllu kerfinu ef um er að ræða mikinn fjölda alloc/dealloc/retain/release símtöl. Læsa þurfti töflunni vegna þráðaöryggis, þannig að ekki var hægt að breyta viðmiðunartölu tveggja hluta í tveimur þráðum á sama tíma. Hins vegar er þetta gildi nýlega sett inn í restina af svokölluðu isa vísbendingar. Þetta er annar lítt áberandi, en mikill kostur og hröðun í framtíðinni. Hins vegar væri aldrei hægt að ná þessu í 32-bita arkitektúr.

Upplýsingar um tengda hluti, hvort hluturinn sé veikt vísað til, hvort nauðsynlegt sé að búa til eyðingarbúnað fyrir hlutinn o.s.frv., eru einnig nýlega settar inn á þann stað sem eftir er af ábendingum á hlutina. Þökk sé þessum upplýsingum er Objective-C Runtime getur í grundvallaratriðum flýtt fyrir keyrslutíma, sem endurspeglast í hraða hvers forrits. Frá prófun þýðir þetta um 40-50% hraða á öllum minnisstjórnunarsímtölum. Bara með því að skipta yfir í 64 bita vísa og nota þetta nýja rými.

Niðurstaða

Þrátt fyrir að keppendur muni reyna að dreifa hugmyndinni um að það sé óþarfi að flytja yfir í 64 bita arkitektúr, þá muntu nú þegar vita að þetta er bara mjög óupplýst skoðun. Það er satt að það að skipta yfir í 64 bita án þess að aðlaga tungumálið þitt eða forrit þýðir í raun ekki neitt - það hægir jafnvel á öllu kerfinu. En nýja A7 notar nútímalegan ARM64 með nýju leiðbeiningasetti og Apple hefur tekið sér það vandræði að nútímavæða allt Objective-C tungumálið og nýta sér nýja möguleika - þess vegna lofað hraðaupphlaup.

Hér höfum við nefnt fjölda ástæðna fyrir því að 64-bita arkitektúr er rétta skrefið fram á við. Þetta er enn ein byltingin „undir hettunni“, þökk sé henni mun Apple reyna að vera í fararbroddi, ekki aðeins með hönnun, notendaviðmót og ríkulegt vistkerfi, heldur aðallega með nútímalegustu tækni á markaðnum.

Heimild: mikeash.com
.