Honza Dvorsky Mike Ash op sy blog toegewy die praktiese implikasies van oorskakeling na 64-bis argitektuur in die iPhone 5S. Hierdie artikel steun op sy bevindinge.
Die rede vir hierdie teks is hoofsaaklik te wyte aan die groot hoeveelheid verkeerde inligting wat versprei word oor wat die nuwe iPhone 5s met 'n 64-bis ARM verwerker eintlik vir gebruikers en die mark beteken. Hier sal ons probeer om objektiewe inligting oor die prestasie, vermoëns en implikasies van hierdie oorgang vir ontwikkelaars te bring.
"64 bit"
Daar is twee dele van 'n verwerker waarna die "X-bis"-etiket kan verwys - die breedte van die heelgetalregisters en die breedte van die wysers. Gelukkig is hierdie breedtes op die meeste moderne verwerkers dieselfde, so in die geval van die A7 beteken dit 64-bis heelgetalregisters en 64-bis wysers.
Dit is egter ewe belangrik om uit te wys wat "64bit" NIE beteken nie: RAM fisiese adres grootte. Die aantal bisse om met RAM te kommunikeer (dus die hoeveelheid RAM wat 'n toestel kan ondersteun) hou nie verband met die aantal SVE bisse nie. ARM-verwerkers het enige plek tussen 26- en 40-bis-adresse en kan onafhanklik van die res van die stelsel verander word.
- Data bus grootte. Die hoeveelheid data wat vanaf RAM of buffergeheue ontvang word, is eweneens onafhanklik van hierdie faktor. Individuele verwerkerinstruksies kan verskillende hoeveelhede data versoek, maar dit word óf in stukke gestuur óf meer as wat nodig is uit die geheue ontvang. Dit hang af van die grootte van die datakwantum. Die iPhone 5 ontvang reeds data van die geheue in 64-bis kwanta (en het 'n 32-bis verwerker), en ons kan groottes tot 192 bisse teëkom.
- Enigiets wat met drywende punt verband hou. Die grootte van sulke registers (FPU) is weer onafhanklik van die interne werking van die verwerker. ARM gebruik 64-bis FPU sedert voor ARM64 (64-bis ARM verwerker).
Algemene voordele en nadele
As ons andersins identiese 32bis- en 64bis-argitekture vergelyk, is hulle oor die algemeen nie so verskillend nie. Dit is een van die redes vir die algemene verwarring van die publiek wat 'n rede soek waarom Apple ook in mobiele toestelle na 64bit beweeg. Dit kom egter alles van die spesifieke parameters van die A7 (ARM64) verwerker en hoe Apple dit gebruik, nie net van die feit dat die verwerker 'n 64-bis argitektuur het nie.
As ons egter steeds na die verskille tussen hierdie twee argitekture kyk, sal ons verskeie verskille vind. Die ooglopende een is dat 64-bis heelgetalregisters 64-bis heelgetalle meer doeltreffend kan hanteer. Selfs voorheen was dit moontlik om met hulle op 32-bis verwerkers te werk, maar dit het gewoonlik beteken om hulle in 32-bis lang stukke te verdeel, wat stadiger berekeninge veroorsaak het. Dus kan 'n 64-bis verwerker oor die algemeen net so vinnig met 64-bis tipes bereken soos met 32-bis. Dit beteken dat toepassings wat gewoonlik 64-bis-tipes gebruik, baie vinniger op 'n 64-bis verwerker kan werk.
Alhoewel 64bit nie die totale hoeveelheid RAM wat die verwerker kan gebruik, beïnvloed nie, kan dit dit makliker maak om met groot stukke RAM in een program te werk. Enige enkele program wat op 'n 32-bis verwerker loop, het slegs ongeveer 4 GB adresspasie. As in ag geneem word dat die bedryfstelsel en standaardbiblioteke iets opneem, laat dit die program met iewers tussen 1-3 GB vir toepassingsgebruik. As 'n 32-bis-stelsel egter meer as 4 GB RAM het, is die gebruik van daardie geheue 'n bietjie meer ingewikkeld. Ons moet die bedryfstelsel dwing om hierdie groter stukke geheue vir ons program te karteer (geheue-virtualisering), of ons kan die program in verskeie prosesse verdeel (waar elke proses weer teoreties 4 GB geheue beskikbaar het vir direkte adressering).
Hierdie "hacks" is egter so moeilik en stadig dat 'n minimum van toepassings dit gebruik. In die praktyk, op 'n 32-bis-verwerker, sal elke program slegs sy 1-3 GB geheue gebruik, en meer beskikbare RAM kan gebruik word om verskeie programme gelyktydig te laat loop of hierdie geheue as 'n buffer te gebruik (kas). Hierdie gebruike is prakties, maar ons wil graag hê dat enige program maklik stukke geheue groter as 4 GB kan gebruik.
Nou kom ons by die gereelde (eintlik verkeerde) bewering dat sonder meer as 4 GB geheue, 'n 64-bis argitektuur nutteloos is. 'n Groter adresspasie is nuttig selfs op 'n stelsel met minder geheue. Geheue-gekarteerde lêers is 'n handige hulpmiddel waar 'n deel van die lêer se inhoud logies aan die proses se geheue gekoppel is sonder dat die hele lêer in die geheue gelaai hoef te word. So kan die stelsel byvoorbeeld geleidelik groot lêers baie keer groter as die RAM-kapasiteit verwerk. Op 'n 32-bis-stelsel kan sulke groot lêers nie betroubaar geheue-gekarteer word nie, terwyl dit op 'n 64-bis stelsel 'n stukkie koek is, danksy die veel groter adresspasie.
Die groter grootte wysers bring egter ook een groot nadeel: andersins benodig identiese programme meer geheue op 'n 64-bis verwerker (hierdie groter wysers moet iewers gestoor word). Aangesien wysers 'n gereelde deel van programme is, kan hierdie verskil die kas belas, wat weer veroorsaak dat die hele stelsel stadiger loop. So in perspektief kan ons sien dat as ons net die verwerker-argitektuur na 64-bis verander, dit eintlik die hele stelsel sou vertraag. Hierdie faktor moet dus gebalanseer word deur meer optimalisering op ander plekke.
ARM64
Die A7, die 64-bis-verwerker wat die nuwe iPhone 5s aandryf, is nie net 'n gewone ARM-verwerker met wyer registers nie. ARM64 bevat groot verbeterings bo die ouer, 32-bis weergawe.
register
ARM64 hou twee keer soveel heelgetalregisters as 32-bis ARM (wees versigtig om nie die aantal en breedte van registers te verwar nie - ons het gepraat oor breedte in die "64-bis" afdeling. So ARM64 het beide twee keer so wye registers en twee keer soveel registers). Die 32-bis ARM het 16 heelgetalregisters: een programteller (PC - bevat die nommer van die huidige instruksie), 'n stapelwyser ('n wyser na 'n funksie wat aan die gang is), 'n skakelregister ('n wyser na die terugkeer na die einde van die funksie), en die oorblywende 13 is vir toepassingsgebruik. Die ARM64 het egter 32 heelgetalregisters, insluitend een nulregister, 'n skakelregister, 'n raamwyser (soortgelyk aan 'n stapelwyser), en een wat vir die toekoms gereserveer is. Dit laat ons met 28 registers vir toepassingsgebruik, meer as dubbel die 32-bis ARM. Terselfdertyd het die ARM64 die aantal swewendepuntgetalregisters (FPU) verdubbel van 16 tot 32 128-bis registers.
Maar hoekom is die aantal registers so belangrik? Geheue is oor die algemeen stadiger as SVE-berekeninge en lees/skryf kan baie lank neem. Dit sal maak dat die vinnige verwerker moet aanhou wag vir geheue en ons sal die natuurlike spoedgrens van die stelsel bereik. Verwerkers probeer om hierdie gestremdheid met lae buffers weg te steek, maar selfs die vinnigste een (L1) is steeds stadiger as die verwerker se berekening. Registers is egter geheueselle direk in die verwerker en hul lees/skryf is vinnig genoeg om nie die verwerker te vertraag nie. Die aantal registers beteken feitlik die hoeveelheid vinnigste geheue vir verwerkerberekeninge, wat die spoed van die hele stelsel grootliks beïnvloed.
Terselfdertyd benodig hierdie spoed goeie optimaliseringsondersteuning van die samesteller, sodat die taal hierdie registers kan gebruik en nie alles in die algemene toepassing (die stadige) geheue hoef te stoor nie.
Instruksiestel
ARM64 bring ook groot veranderinge aan die instruksiestel. 'n Instruksiestel is 'n stel atoombewerkings wat 'n verwerker kan uitvoer (bv. 'ADD register1 register2' voeg die getalle in twee registers by). Die funksies wat vir individuele tale beskikbaar is, is saamgestel uit hierdie instruksies. Meer komplekse funksies moet meer instruksies uitvoer, sodat hulle stadiger kan wees.
Nuut in ARM64 is instruksies vir AES-enkripsie, SHA-1 en SHA-256 hash-funksies. So in plaas van 'n komplekse implementering, sal slegs die taal hierdie instruksie noem - wat 'n groot versnelling sal bring in die berekening van sulke funksies en hopelik bykomende sekuriteit in toepassings. Bv. die nuwe Touch ID gebruik ook hierdie instruksies in enkripsie, wat werklike spoed en sekuriteit moontlik maak (in teorie sal 'n aanvaller die verwerker self moet verander om toegang tot die data te verkry - wat onprakties is om die minste te sê gegewe die miniatuurgrootte daarvan).
Verenigbaarheid met 32bit
Dit is belangrik om te noem dat die A7 volledig in 32-bis-modus kan werk sonder dat dit nodig is om na te boots. Dit beteken dat die nuwe iPhone 5s toepassings kan laat loop wat op 32-bis ARM saamgestel is sonder enige verlangsaming. Dit kan egter nie die nuwe ARM64-funksies gebruik nie, so dit is altyd die moeite werd om 'n spesiale bouwerk net vir die A7 te maak, wat baie vinniger behoort te loop.
Looptyd verander
Looptyd is die kode wat funksies by die programmeertaal voeg, wat dit kan gebruik terwyl die toepassing loop, tot na vertaling. Aangesien Apple nie toepassingsversoenbaarheid hoef te handhaaf nie (dat 'n 64-bis-binêr op 32-bis loop), kan hulle bekostig om nog 'n paar verbeterings aan die Objective-C-taal aan te bring.
Een van hulle is die sg gemerkte wyser (gemerkte aanwyser). Normaalweg word voorwerpe en wysers na daardie voorwerpe in afsonderlike dele van geheue gestoor. Nuwe wysertipes laat klasse met min data egter toe om voorwerpe direk in die wyser te stoor. Hierdie stap elimineer die behoefte om geheue direk vir die voorwerp toe te ken, skep net 'n wyser en die voorwerp daarin. Gemerkte wysers word slegs in 64-bis-argitektuur ondersteun, ook as gevolg van die feit dat daar nie meer genoeg spasie in 'n 32-bis-wyser is om genoeg nuttige data te stoor nie. Daarom het iOS, anders as OS X, nog nie hierdie kenmerk ondersteun nie. Met die koms van ARM64 is dit egter besig om te verander, en iOS het OS X ook in hierdie verband ingehaal.
Alhoewel wysers 64 bisse lank is, word op die ARM64 slegs 33 bisse vir die wyser se eie adres gebruik. En as ons die res van die wyserstukke betroubaar kan ontmasker, kan ons hierdie spasie gebruik om bykomende data te stoor – soos in die geval van die genoemde gemerkte wysers. Konseptueel is dit een van die grootste veranderinge in die geskiedenis van Objective-C, hoewel dit nie 'n bemarkbare kenmerk is nie - so die meeste gebruikers sal nie weet hoe Apple Objective-C vorentoe beweeg nie.
Wat die nuttige data betref wat in die oorblywende spasie van so 'n gemerkte wyser gestoor kan word, gebruik Objective-C dit byvoorbeeld nou om die sg. verwysingtelling (aantal verwysings). Voorheen is die verwysingtelling op 'n ander plek in die geheue gestoor, in 'n hash-tabel wat daarvoor voorberei is, maar dit kan die hele stelsel vertraag in die geval van 'n groot aantal alloc/dealloc/retain/release-oproepe. Die tafel moes gesluit word weens draadveiligheid, dus kon die verwysingtelling van twee voorwerpe in twee drade nie gelyktydig verander word nie. Hierdie waarde is egter nuut ingevoeg in die res van die sogenaamde Isa aanwysers. Dit is nog 'n onopvallende, maar groot voordeel en versnelling in die toekoms. Dit kon egter nooit in 'n 32-bis-argitektuur bereik word nie.
Inligting oor geassosieerde voorwerpe, of die voorwerp swak verwys word, of dit nodig is om 'n vernietiger vir die voorwerp te genereer, ens., word ook nuut ingevoeg in die oorblywende plek van wysers na die voorwerpe. Danksy hierdie inligting, die Objective-C runtime is in staat om die looptyd fundamenteel te versnel, wat in die spoed van elke toepassing weerspieël word. Van toetsing beteken dit ongeveer 40-50% versnelling van alle geheuebestuuroproepe. Net deur oor te skakel na 64-bis wysers en hierdie nuwe spasie te gebruik.
Afsluiting
Alhoewel mededingers die idee sal probeer versprei dat oorskakeling na 'n 64-bis-argitektuur onnodig is, sal jy reeds weet dat dit net 'n baie oningeligte mening is. Dit is waar dat om na 64-bis oor te skakel sonder om jou taal of toepassings aan te pas, niks regtig beteken nie – dit vertraag selfs die hele stelsel. Maar die nuwe A7 gebruik 'n moderne ARM64 met 'n nuwe instruksiestel, en Apple het die moeite gedoen om die hele Objective-C-taal te moderniseer en voordeel te trek uit die nuwe vermoëns - vandaar die beloofde versnelling.
Hier het ons 'n groot aantal redes genoem waarom 'n 64-bis argitektuur die regte stap vorentoe is. Dit is nog 'n rewolusie "onder die enjinkap", waardeur Apple sal probeer om aan die voorpunt te bly nie net met ontwerp, gebruikerskoppelvlak en ryk ekosisteem nie, maar hoofsaaklik met die mees moderne tegnologie op die mark.
Baie oningeligte Android/Samsung-mense moet hierdie artikel lees en dan in die hoek wegkruip.
Wel, ons moet jammer voel vir hulle. Hulle het jare lank die tragiese UX en UI van Android verskoon deur te sê dat hulle die mees tegnologies gevorderde bedryfstelsel met funksies het en nou het hulle uitgevind dat hulle weer jare agter is :)
As 'n persoon nie 'n skaap is nie en na advertensies luister (en hy is goed daarmee), dan kan hy na persoonlike ondervinding sy eie opinie vorm :-).
Ek probeer amper al die kompetisie en vorm my eie opinie.
Vir my het ek ’n nuwe superhoëprestasie-selfoon nodig, want ek bestee nie veel daaraan nie. Dit is Ek het minder prestasie vir minder prys nodig ;-). Miskien sal ek 'n stadiger een met 'n groter battery verkies.
Aan die ander kant sal die nuwe procak nuttig wees vir die iPad waar daar baie speletjies is :-).
Ek is Android/HTC :) want DIT is nogal lekker vir my en die wortel en die omskakeling van hoë kwaliteit HW in 'n vinnige vegter is my stokperdjie. En iOS laat my dit nie doen nie. (Dis nie eers nodig nie. Min of meer, iOS is so ontwerp dat alles werk soos dit moet en jy hoef niks daar te doen nie. Wanneer ek ophou speel geniet, sal ek 'n appel koop en dit geniet). Maar ek weet nie hoekom julle mekaar soos kinders aanhou aanval nie. Apple is heeltemal soos Android. Dit is soos om Demokrasie met Diktatuur en dies meer te vergelyk... Ek het die konferensie gekyk toe die iPhone 5S bekend gestel is en ten spyte van die feit dat ek niks van Apple besit nie, het ek gehou van die 64bit en ander verbeterings wat gekom het. Maar nie omdat ek 'n komplekse honimír trtko is wat agter 'n rekenaar sit en Android of Apple jaag nie, maar omdat ek die VORDERING sien wat my nie lank sal laat wag nie. Mense moet regtig hard begin werk sodat hulle nie tyd het om snert te hanteer nie, om dit beleefd te stel.
konstruktiewe bydrae van die ander kant :) kiez dit sal die oë van die oorblywende 99% android positief oopmaak
miskien moet 99% van appelfanatici eers bespreek word, dan kan ons 'n konstruktiewe gesprek voer
baie komplekse dinge eenvoudig verduidelik ... dankie
Puik artikel! Ja, ek stem saam dat Android/WP-gebruikers hierdie artikel as 'n moet moet lees. In plaas daarvan om te trol en slim te praat oor "hoe 64b nutteloos is in selfone" ...
jy het seker nooit 'n wp in jou hand gehad nie, anders sou jy dit nie gehad het nie
Sedert sy eerste suksesse in die mobiele mark het Samsung niks anders gedoen as om die mededinging te smeer nie, maar in wese het hy al die tyd in sy voetspore gevolg. Apple was nog altyd ’n rolmodel vir tegnologiemaatskappye, en as hulle net daarop fokus om kliënte te bespot en voortdurend verkeerde inligting te gee, sal hulle binnekort struikel. Apple het nog altyd sy eie pad gegaan en dit was nog altyd 'n kwessie van baie goeie tydsberekening, wat baie mededingende maatskappye in die bedryf kort.
’n Mens kan sê dat Samsung die golf ry en sy moontlikhede benut. Hy wed op Android, hy het wonderlike HW, hy maak baie dinge self, hy het ordentlike ondersteuning. En soos enige roofsugtige Asiatiese maatskappy, gebruik dit al die moontlikhede van advertensies. En natuurlik steel en kopieer hy. Waarmee “skuins oë” goed is, is kopieer. Hulle het baie goed bereken dat dit baie goedkoper is as om stap vir stap op hul eie pad te gaan. En as 'n sterk maatskappy kan hy dit eenvoudig bekostig. Tog …
Ek verstaan net nie hoekom die foon se spoed aanhou toeneem nie, gee vir my 'n paar voorbeelde van waarvoor jy dit gebruik, dit maak stadig vir my geen sin om die werkverrigting van die selfoon te verhoog nie, maar ek sal die woord bemarking verwyder.
Speletjies, swak geoptimaliseerde speletjies. Transport Tycoon op iPad 3 werk ook nie so glad en in dieselfde resolusie as op die lessenaar nie. Voorbeeld.
Ek verstaan net nie hoekom die spoed van die foon aanhou toeneem nie, gee vir my 'n paar voorbeelde van waarvoor jy dit gebruik, dit maak stadig vir my geen sin om die werkverrigting van die selfoon te verhoog nie, as ek die woord bemarking daaruit verwyder .
Vir video-, klank- en beeldverwerking. En na die speletjies.
Enigiemand wat 'n iPhone net gebruik om te bel, SMS'e te stuur, en af en toe e-posse te lees of te stuur en af en toe op die internet te blaai, sal 'n iPhone 4 nodig hê. Ek glo daar is baie sulke gebruikers. Nie almal het die beste foon in die wêreld nodig nie :-)
skape
Beteken die fisiese afweging tussen hardeware en sagteware niks vir jou nie? Dit laat my 'n bietjie dink aan die einde van die 19de eeu, toe die fisici van daardie tyd gesê het dat alles in fisika reeds ontdek is en dat dit nie nodig was om voort te gaan nie ('n dekade voor die relatiwiteitsteorie en drie voor die kwantumteorie). .
Die strewe na die beste eindig nooit nie. Soms lei die sagteware en soms die hardeware. Maar as die een vashaak, sal dit nie die ander een laat gaan nie. Ons sal nie so selfsugtig teenoor ons nageslag wees nie :) So aan jou kommentaar - 'n vinniger foon sal kragtiger toepassings moontlik maak, wat baie meer as dryf sal kan doen. En eens dinge waarvoor selfs vandag se rekenaars nie genoeg is nie. Die toekoms is opwindend.
Presies :)
Lekker artikel, maar ek verstaan nie hoekom Apple nie 7GB RAM in die A2 gesit het nie. Ja, iOS-multitasking is nie sodanig dat 2GB noodwendig nodig is nie, maar gegewe die twee keer die lengte van die geheuewyser, sal dit baie meer geskik wees.
Maar andersins stem ek saam dat 'n 64-bis verwerker "onnodig" is vir 'n selfoon, net soos 'n retina-skerm of 'n optiese muis in plaas van 'n bal onnodig was - al hierdie uitvindings is as "onnodig" bestempel, maar na my mening is die korrekte woord is "tydloos", want een keer moet kom en Apple is nie bang om met iets nuuts vorendag te kom nie.
Ek sekondeer dit. Ongelukkig is selfs "nutteloos" nie 'n akkurate uitdrukking nie. Onnodig beteken iets waarvan 'n persoon nie die prioriteit ken nie. Dit is beslis nie waar nie. Spoed benodig dalk nie sulke spoed nie, maar dit sal dit beslis herken. En wanneer die sagteware die hardeware inhaal, sal daar weer ruimte vir verbetering wees.
Sekerlik, ek is ten gunste, ek bedoel die iP5 is regtig 'n redelik vinnige slimfoon, so die 5S hoef glad nie 64bis te wees nie. Maar eendag moes iemand dit weer hanteer en dit was Apple en dit was nou. Vir so lank as wat ek kan onthou, het kenners ook gepraat oor hoe 64-bis verwerkers selfs in rekenaars nutteloos sal wees.
Vir my, as IT-leek wat amper matriek gedruip het, is die gevolgtrekking belangrik. Die hele artikel (ondersteun deur die kommentaar) lyk vir my nogal insiggewend, en hoewel ek dit nie sal kan verduidelik nie, is die A7 met 64-bis argitektuur 'n stap vorentoe. Dankie vir die inligting.
Ek sal die titel van die artikel wysig, aangesien dit 'n bemarkingsskuif is. Elke innovasie is in wese 'n bemarkingsskuif. :-)
Ek dink nie. Samsung gebruik byvoorbeeld bemarkingsbewegings. Hulle verskyn met RAM, wat die iPhone glad nie nodig het nie. Hulle kom weg met kenmerke wat glad nie bruikbaar is nie. Hul doelbewus verhoging van verwerker prestasie vir toetse. Ens. Dit is bemarking, alhoewel ja, dit is misleidend, waarmee hulle nie net moet wegkom nie ;)