Honza Dvorsky Mike Ash pühendatud tema blogile iPhone 64S 5-bitisele arhitektuurile ülemineku praktilised tagajärjed. See artikkel tugineb tema leidudele.
Selle teksti põhjuseks on peamiselt levitatud suur hulk valeinfot selle kohta, mida uus 5-bitise ARM-protsessoriga iPhone 64s kasutajate ja turu jaoks tegelikult tähendab. Siin püüame tuua arendajatele objektiivset teavet selle ülemineku toimivuse, võimaluste ja tagajärgede kohta.
"64 bitti"
Protsessoril on kaks osa, millele "X-bitine" silt võib viidata – täisarvude registrite laius ja osutite laius. Õnneks on enamikul kaasaegsetel protsessoritel need laiused samad, nii et A7 puhul tähendab see 64-bitiseid täisarvude registreid ja 64-bitiseid viiteid.
Siiski on sama oluline välja tuua, mida "64bit" EI tähenda: RAM-i füüsilise aadressi suurus. RAM-iga suhtlemiseks vajalike bittide arv (seega RAM-i hulk, mida seade toetab) ei ole seotud protsessori bittide arvuga. ARM-protsessoritel on 26-40-bitised aadressid ja neid saab muust süsteemist sõltumatult muuta.
- Andmesiini suurus. RAM-ist või puhvermälust vastuvõetud andmemaht on samuti sellest tegurist sõltumatu. Üksikud protsessori käsud võivad nõuda erineval hulgal andmeid, kuid need saadetakse kas tükkidena või võetakse mälust vastu rohkem kui vaja. See sõltub andmekvanti suurusest. IPhone 5 saab mälust andmeid juba 64-bitise kvantitena (ja sellel on 32-bitine protsessor) ning me võime kohata kuni 192-bitise suurusega suurusi.
- Kõik, mis on seotud ujukomaga. Selliste registrite (FPU) suurus ei sõltu jällegi protsessori sisemisest tööst. ARM on kasutanud 64-bitist FPU-d juba enne ARM64 (64-bitine ARM-protsessor).
Üldised eelised ja puudused
Kui võrrelda muidu identseid 32- ja 64-bitiseid arhitektuure, siis üldiselt need nii erinevad ei ole. See on üks põhjusi, miks avalikkus on üldiselt segaduses, mis otsib põhjust, miks Apple liigub ka mobiilseadmetes 64-bitisele. See kõik tuleneb aga A7 (ARM64) protsessori spetsiifilistest parameetritest ja sellest, kuidas Apple seda kasutab, mitte ainult sellest, et protsessoril on 64-bitine arhitektuur.
Kui me siiski vaatame nende kahe arhitektuuri erinevusi, leiame mitmeid erinevusi. Ilmselge on see, et 64-bitised täisarvude registrid saavad 64-bitiste täisarvudega tõhusamalt hakkama. Juba varem oli nendega võimalik töötada 32-bitiste protsessoritega, kuid see tähendas tavaliselt nende jagamist 32-bitisteks tükkideks, mis põhjustas aeglasemaid arvutusi. Nii et 64-bitine protsessor suudab üldiselt arvutada 64-bitiste tüüpidega sama kiiresti kui 32-bitiste puhul. See tähendab, et üldiselt 64-bitisi tüüpe kasutavad rakendused võivad 64-bitise protsessoriga palju kiiremini töötada.
Kuigi 64-bitine ei mõjuta protsessori kasutatava RAM-i koguhulka, võib see lihtsustada suurte RAM-i tükkidega töötamist ühes programmis. Igal üksikul 32-bitisel protsessoril töötaval programmil on ainult umbes 4 GB aadressiruumi. Arvestades, et operatsioonisüsteem ja standardteegid võtavad midagi, jätab see programmile rakenduste kasutamiseks kuskil 1-3 GB. Kui aga 32-bitisel süsteemil on rohkem kui 4 GB muutmälu, on selle mälu kasutamine veidi keerulisem. Peame sundima operatsioonisüsteemi neid suuremaid mälutükke meie programmi jaoks kaardistama (mälu virtualiseerimine) või saame programmi jagada mitmeks protsessiks (kus igas protsessis on teoreetiliselt jällegi 4 GB mälu otseaadresseerimiseks).
Need "häkkimised" on aga nii keerulised ja aeglased, et minimaalsed rakendused kasutavad neid. Praktikas kasutab 32-bitise protsessori puhul iga programm ainult oma 1–3 GB mälu ja rohkem vaba RAM-i saab kasutada mitme programmi samaaegseks käitamiseks või selle mälu puhvrina (vahemällu salvestamiseks). Need kasutusvõimalused on praktilised, kuid sooviksime, et mis tahes programmid saaksid hõlpsalt kasutada rohkem kui 4 GB mälu.
Nüüd jõuame sagedase (tegelikult ebaõige) väiteni, et ilma rohkem kui 4 GB mäluta pole 64-bitine arhitektuur kasutu. Suurem aadressiruum on kasulik isegi väiksema mäluga süsteemis. Mäluga kaardistatud failid on mugav tööriist, kus osa faili sisust on loogiliselt seotud protsessi mäluga, ilma et kogu faili tuleks mällu laadida. Süsteem suudab näiteks järk-järgult töödelda suuri faile, mis on kordades suuremad kui RAM-i maht. 32-bitises süsteemis ei saa nii suuri faile usaldusväärselt mälukaardistada, samas kui 64-bitises süsteemis on see tänu palju suuremale aadressiruumile käkitegu.
Osutite suurem suurus toob aga kaasa ka ühe suure miinuse: muidu vajavad identsed programmid 64-bitise protsessori peal rohkem mälu (need suuremad osutid tuleb kuhugi salvestada). Kuna osutid on programmide sagedane osa, võib see erinevus koormata vahemälu, mis omakorda põhjustab kogu süsteemi aeglasemalt töötamist. Perspektiivis näeme, et kui muudaksime protsessori arhitektuuri 64-bitiseks, aeglustaks see tegelikult kogu süsteemi. Seega tuleb seda tegurit tasakaalustada muudes kohtades tehtava suurema optimeerimisega.
ARM64
A7, 64-bitine protsessor, mis toidab uut iPhone 5s, ei ole lihtsalt tavaline ARM-protsessor, millel on laiemad registrid. ARM64 sisaldab suuri täiustusi võrreldes vanema, 32-bitise versiooniga.
registri
ARM64 mahutab kaks korda rohkem täisarvude registreid kui 32-bitine ARM (olge ettevaatlik, et mitte segamini ajada registrite arvu ja laiust – laiusest rääkisime jaotises "64-bitine". Seega on ARM64-l nii kaks korda laiemaid kui ka kaks korda rohkem registreid registrid). 32-bitisel ARM-il on 16 täisarvu registrit: üks programmiloendur (PC - sisaldab jooksva käsu numbrit), pinukursor (osuti pooleliolevale funktsioonile), lingiregister (osuti lõppu tagasitulemisele). funktsioonist) ja ülejäänud 13 on mõeldud kasutamiseks rakendustes. Siiski on ARM64-l 32 täisarvu registrit, sealhulgas üks nullregister, lingiregister, kaadrikursor (sarnaselt viru osutiga) ja üks tuleviku jaoks reserveeritud. See jätab meile rakenduste kasutamiseks 28 registrit, mis on enam kui kaks korda suurem kui 32-bitine ARM. Samal ajal kahekordistas ARM64 ujukomaarvu (FPU) registrite arvu 16-lt 32-le 128-bitisele registrile.
Aga miks on registrite arv nii oluline? Mälu on üldiselt aeglasem kui CPU arvutused ja lugemine/kirjutamine võib võtta väga kaua aega. See sunniks kiiret protsessorit jääma mälu ootama ja me saavutaksime süsteemi loomuliku kiirusepiirangu. Protsessorid püüavad seda puuet puhvrite kihtidega varjata, kuid isegi kõige kiirem (L1) on protsessori arvutustest siiski aeglasem. Samas on registrid mäluelemendid otse protsessoris ja nende lugemine/kirjutamine on piisavalt kiire, et protsessorit mitte aeglustada. Registrite arv tähendab praktiliselt kõige kiirema mälu mahtu protsessoriarvutuste jaoks, mis mõjutab suuresti kogu süsteemi kiirust.
Samas vajab see kiirus kompilaatorilt head optimeerimise tuge, et keel saaks neid registreid kasutada ja ei peaks kõike üldrakenduse (aeglase) mällu salvestama.
Juhendi komplekt
ARM64 toob suuri muudatusi ka juhiste komplekti. Käskude komplekt on aatomoperatsioonide kogum, mida protsessor saab sooritada (nt 'ADD register1 register2' liidab kahes registris olevad numbrid). Üksikute keelte jaoks saadaolevad funktsioonid koosnevad nendest juhistest. Keerulisemad funktsioonid peavad täitma rohkem käske, nii et need võivad olla aeglasemad.
Uued ARM64-s on juhised AES-krüptimise, SHA-1 ja SHA-256 räsifunktsioonide jaoks. Nii et keeruka teostuse asemel nimetab seda juhist ainult keel - mis kiirendab selliste funktsioonide arvutamist ja loodetavasti lisab rakenduste turvalisust. Nt. uus Touch ID kasutab neid juhiseid ka krüptimisel, võimaldades tõelist kiirust ja turvalisust (teoreetiliselt peaks ründaja andmetele juurdepääsuks protsessorit ise muutma – see on selle miniatuurset suurust arvestades pehmelt öeldes ebapraktiline).
Ühilduvus 32-bitisega
Oluline on mainida, et A7 saab täielikult töötada 32-bitises režiimis, ilma et oleks vaja emuleerida. See tähendab, et uus iPhone 5s suudab ilma aeglustumiseta käivitada 32-bitisele ARM-ile koostatud rakendusi. Siis aga ei saa ta kasutada uusi ARM64 funktsioone, mistõttu tasub alati teha spetsiaalne build just A7 jaoks, mis peaks palju kiiremini jooksma.
Käitusaja muudatused
Runtime on kood, mis lisab programmeerimiskeelele funktsioone, mida see saab kasutada rakenduse töötamise ajal kuni pärast tõlkimist. Kuna Apple ei pea säilitama rakenduste ühilduvust (64-bitine kahendfail töötab 32-bitises versioonis), võiksid nad endale lubada Objective-C keelele veel mõned täiustused.
Üks neist on nn märgistatud kursor (märgitud osuti). Tavaliselt salvestatakse objektid ja osutajad nendele objektidele mälu eraldi osades. Uued osutitüübid võimaldavad aga väheste andmetega klassidel objekte otse kursorisse salvestada. See samm välistab vajaduse eraldada objektile otse mälu, lihtsalt looge kursor ja objekt selle sees. Sildistatud viiteid toetatakse ainult 64-bitises arhitektuuris ka seetõttu, et 32-bitises kursoris ei ole enam piisavalt ruumi piisavalt kasulike andmete salvestamiseks. Seetõttu iOS erinevalt OS X-st seda funktsiooni veel ei toetanud. ARM64 tulekuga on see aga muutumas ja iOS on ka selles osas OS X-le järele jõudnud.
Kuigi osutid on 64 bitti pikad, kasutatakse ARM64 puhul kursori enda aadressi jaoks vaid 33 bitti. Ja kui suudame ülejäänud osutibitid usaldusväärselt paljastada, saame seda ruumi kasutada täiendavate andmete salvestamiseks – nagu mainitud märgistatud osutite puhul. Kontseptuaalselt on see üks suurimaid muudatusi Objective-C ajaloos, kuigi see ei ole turustatav funktsioon – nii et enamik kasutajaid ei tea, kuidas Apple Objective-C edasi liigub.
Mis puudutab kasulikke andmeid, mida saab salvestada sellise märgistatud osuti ülejäänud ruumi, siis näiteks Objective-C kasutab seda nüüd nn. viidete arv (viidete arv). Varem oli viiteloendus salvestatud mällu teise kohta, selle jaoks koostatud räsitabelisse, kuid see võib suure hulga alloc/dealloc/retain/release kõnede korral kogu süsteemi pidurdada. Tabel tuli keerme ohutuse tõttu lukustada, nii et kahe lõime kahe objekti võrdlusarvu ei saanud korraga muuta. See väärtus sisestatakse aga äsja ülejäänud nn ISA näitajad. See on veel üks silmapaistmatu, kuid tohutu eelis ja kiirendus tulevikus. 32-bitises arhitektuuris pole seda aga kunagi võimalik saavutada.
Objektidele osutavate osutite allesjäänud kohta sisestatakse ka äsja teave seotud objektide kohta, kas objekt on nõrgalt viidatud, kas objektile on vaja genereerida destruktorit jne. Tänu sellele teabele on Objective-C käitusaeg suudab tööaega põhimõtteliselt kiirendada, mis kajastub iga rakenduse kiiruses. Testimise põhjal tähendab see kõigi mäluhalduskõnede kiirust umbes 40–50%. Lihtsalt lülitades üle 64-bitistele osutitele ja kasutades seda uut ruumi.
Järeldus
Kuigi konkurendid püüavad levitada ideed, et 64-bitisele arhitektuurile üleminek on tarbetu, teate juba, et see on lihtsalt väga informeerimata arvamus. On tõsi, et 64-bitisele üleminek ilma keelt või rakendusi kohandamata ei tähenda tegelikult midagi – see isegi aeglustab kogu süsteemi tööd. Kuid uus A7 kasutab kaasaegset ARM64 koos uue juhistega ning Apple on võtnud vaevaks kogu Objective-C keelt moderniseerida ja uusi võimalusi ära kasutada – sellest ka lubatud kiirendus.
Siin oleme maininud mitmeid põhjuseid, miks 64-bitine arhitektuur on õige samm edasi. Tegemist on järjekordse revolutsiooniga "kapoti all", tänu millele püüab Apple esirinnas püsida mitte ainult disaini, kasutajaliidese ja rikkaliku ökosüsteemi, vaid peamiselt kõige kaasaegsemate tehnoloogiatega turul.
Paljud väheteadlikud Androidi/Samsungi inimesed peaksid selle artikli läbi lugema ja seejärel nurka peitma.
Noh, meil on neist kahju. Aastaid vabandasid nad Androidi traagilist UX-i ja kasutajaliidest, öeldes, et neil on tehnoloogiliselt kõige arenenum funktsioonidega OS ja nüüd said nad teada, et on jälle aastaid maas :)
Kui inimene ei ole lammas ja kuulab reklaame (ja ta on selles hea), siis pärast isiklikku kogemust saab ta oma arvamuse kujundada :-).
Proovin peaaegu kõiki võistlusi ja kujundan oma arvamuse.
Minu jaoks on mul vaja uut ülivõimsat mobiiltelefoni, sest ma ei kuluta sellele palju. See on Ma vajan vähem jõudlust madalama hinna eest ;-). Võib-olla eelistaksin suurema akuga aeglasemat.
See-eest oleks uus procak kasulik iPadile, kus on palju mänge :-).
Olen Android/HTC :) sest see on minu jaoks päris lõbus ja kvaliteetse HW rootimine ja kiireks võitlejaks konverteerimine on minu hobi. Ja iOS ei luba mul seda teha. (See pole isegi vajalik. Enam-vähem iOS on loodud nii, et kõik töötab nii nagu peab ja seal ei pea midagi tegema. Kui ma mängimise nautimise lõpetan, ostan õuna ja naudin seda). Aga ma ei tea, miks te muudkui ründate üksteist nagu lapsed. Apple on täiesti nagu Android. See on nagu demokraatia võrdlemine diktatuuri ja muu sellisega... Vaatasin konverentsi iPhone 5S esitlemise ajal ja vaatamata sellele, et ma Apple'ilt midagi ei oma, meeldis mulle 64bit ja muud täiustused, mis tulid. Kuid mitte sellepärast, et ma oleksin keeruline honimír trtko, kes istub arvuti taga ja ajab taga Androidi või Apple'i, vaid sellepärast, et ma näen PROGRESSI, mis ei lase mul kaua oodata. Inimesed peaksid hakkama tõsiselt pingutama, et neil ei jääks aega viisakalt öeldes jamadega tegeleda.
konstruktiivne panus teiselt poolt :) kiez see avaks silmad ülejäänud 99% android positiivne
võib-olla tuleks 99% õunafanaatikutest enne läbi arutada, siis saame konstruktiivselt vestelda
väga keerulised asjad lihtsalt seletatud... aitäh
Suurepärane artikkel! Jah, olen nõus, et Androidi/WP kasutajad peaksid seda artiklit kindlasti lugema. Selle asemel, et trallitada ja targalt rääkida, "kuidas 64b on mobiilides kasutu"…
sul pole vist kunagi wp käes olnud, muidu sul seda ei oleks
Alates oma esimestest edusammudest mobiiliturul pole Samsung muud teinud, kui konkurentsi määrinud, kuid sisuliselt on ta kogu selle aja tema jälgedes käinud. Apple on tehnoloogiaettevõtetele alati eeskujuks olnud ja kui nad keskenduvad vaid klientide mõnitamisele ja pidevale desinformeerimisele, siis nad varsti komistavad. Apple on alati läinud oma teed ja alati on olnud küsimus väga heas ajastuses, millest paljudel valdkonna konkureerivatel ettevõtetel puudub.
Võiks öelda, et Samsung sõidab lainel ja kasutab oma võimalusi ära. Ta panustas Androidile, tal on suurepärane HW, ta teeb palju asju ise, tal on korralik tugi. Ja nagu iga röövellik Aasia ettevõte, kasutab see kõiki reklaamimise võimalusi. Ja muidugi ta varastab ja kopeerib. Mida "viltusilmne" oskab, on kopeerimine. Nad on väga hästi välja arvutanud, et see on palju odavam, kui minna oma teed, samm-sammult. Ja tugeva ettevõttena saab ta seda endale lihtsalt lubada. Ometi…
Ma lihtsalt ei saa aru, miks telefoni kiirus muudkui kasvab, tooge mõni näide milleks te seda kasutate, vaikselt pole minu jaoks mõtet mobiiltelefoni jõudlust tõsta, aga sõna turundus eemaldan.
Mängud, halvasti optimeeritud mängud. Samuti ei tööta iPad 3 Transport Tycoon nii sujuvalt ja sama eraldusvõimega kui töölaual. Näide.
Ma lihtsalt ei saa aru, miks telefoni kiirus muudkui kasvab, tooge mõni näide milleks te seda kasutate, mul pole mõtet aeglaselt mobiiltelefoni jõudlust tõsta, kui sealt sõna turundus ära võtta .
Video-, heli- ja pilditöötluseks. Ja edasi mängude juurde.
Igaüks, kes kasutab iPhone'i ainult helistamiseks, sõnumite saatmiseks ja aeg-ajalt e-kirjade lugemiseks või saatmiseks ning aeg-ajalt Internetis surfamiseks, vajab iPhone 4. Usun, et selliseid kasutajaid on palju. Kõik ei vaja maailma parimat telefoni :-)
lambad
Kas riist- ja tarkvara füüsiline kompromiss ei tähenda teile midagi? See meenutab mulle natuke 19. sajandi lõppu, kui tolleaegsed füüsikud ütlesid, et füüsikas on kõik juba avastatud ja pole vaja jätkata (kümmekond enne relatiivsusteooriat ja kolm enne kvantteooriat) .
Parima poole püüdlemine ei lõpe kunagi. Mõnikord viib tarkvara ja mõnikord riistvara. Aga kui üks jääb kinni, ei lase see teist lahti. Oma järglaste suhtes me nii isekad ei ole :) Nii et teie kommentaariks - kiirem telefon võimaldab võimsamaid rakendusi, mis suudavad teha palju enamat kui sõita. Ja kunagi asju, mille jaoks isegi tänapäeva arvutitest ei piisa. Tulevik on põnev.
Täpselt :)
Tore artikkel, aga ma ei saa aru, miks Apple ei pannud A7-sse 2 GB muutmälu. Jah, iOS-i multitegumtöö ei ole selline, et 2GB oleks ilmtingimata vaja, aga mäluosuti kahekordset pikkust arvestades oleks see palju sobivam.
Aga muidu olen nõus, et 64-bitine protsessor on mobiiltelefoni jaoks "ebavajalik", nagu oli ebavajalik võrkkesta ekraan või palli asemel optiline hiir - kõik need leiutised said sildi "tarbetu", kuid minu arvates õige sõna on "ajatu", sest üks kord peab tulema ja Apple ei karda midagi uut välja mõelda.
Ma toetan seda. Kahjuks pole isegi "kasutu" täpne väljend. Ebavajalik tähendab midagi, mille prioriteetsust inimene ei tea. See pole kindlasti tõsi. Kiirus ei pruugi sellist kiirust vajada, kuid see tunneb selle kindlasti ära. Ja kui tarkvara riistvarale järele jõuab, on jälle arenguruumi.
Muidugi, ma olen poolt, ma mõtlen, et iP5 on tõesti üsna kiire nutitelefon, nii et 5S ei pea olema üldse 64-bitine. Kuid ühel päeval pidi keegi sellega uuesti tegelema ja see oli Apple ja see oli nüüd. Nii kaua kui ma mäletan, on eksperdid rääkinud ka sellest, kuidas 64-bitised protsessorid jäävad kasutuks isegi arvutites.
Minu kui IT-võhiku jaoks, kes peaaegu läbi kukkus maatrika, on järeldus oluline. Kogu artikkel (mida toetavad kommentaarid) tundub mulle üsna läbinägelik ja kuigi ma ei oska seda seletada, on 7-bitise arhitektuuriga A64 samm edasi. Tänan info eest.
Muudaksin artikli pealkirja, kuna see on turunduslik käik. Iga uuendus on sisuliselt turunduskäik. :-)
Ma ei arva. Näiteks Samsung kasutab turunduslikke samme. Need kuvatakse RAM-iga, mida iPhone üldse ei vaja. Nad pääsevad funktsioonidest, mis pole üldse kasutatavad. Nad suurendavad sihilikult protsessori jõudlust testide jaoks. Jne. See on turundus, kuigi jah, see on eksitav, millest nad ei peaks niisama pääsema ;)