Honza Dvorsky Mike Ash dedikert på bloggen hans de praktiske implikasjonene av å bytte til 64-bits arkitektur i iPhone 5S. Denne artikkelen bygger på funnene hans.
Årsaken til denne teksten skyldes hovedsakelig den store mengden feilinformasjon som spres om hva den nye iPhone 5s med 64-bits ARM-prosessor faktisk betyr for brukere og markedet. Her vil vi prøve å bringe objektiv informasjon om ytelsen, mulighetene og implikasjonene av denne overgangen for utviklere.
"64 bit"
Det er to deler av en prosessor som "X-bit"-etiketten kan referere til - bredden på heltallsregistrene og bredden på pekerne. Heldigvis er disse breddene de samme på de fleste moderne prosessorer, så i tilfellet med A7 betyr dette 64-bits heltallsregistre og 64-bits pekere.
Det er imidlertid like viktig å påpeke hva "64bit" IKKE betyr: RAM fysisk adressestørrelse. Antall biter som skal kommuniseres med RAM (dermed mengden RAM en enhet kan støtte) er ikke relatert til antall CPU-biter. ARM-prosessorer har hvor som helst mellom 26- og 40-biters adresser og kan endres uavhengig av resten av systemet.
- Databuss størrelse. Mengden data som mottas fra RAM eller bufferminne er på samme måte uavhengig av denne faktoren. Individuelle prosessorinstruksjoner kan be om forskjellige mengder data, men de sendes enten i biter eller mottas mer enn nødvendig fra minnet. Det avhenger av størrelsen på datakvantumet. iPhone 5 mottar allerede data fra minnet i 64-bits kvanta (og har en 32-bits prosessor), og vi kan møte størrelser på opptil 192 biter.
- Alt relatert til flytepunkt. Størrelsen på slike registre (FPU) er igjen uavhengig av prosessorens interne virkemåte. ARM har brukt 64-bit FPU siden før ARM64 (64-bit ARM-prosessor).
Generelle fordeler og ulemper
Hvis vi sammenligner ellers identiske 32bit og 64bit arkitekturer, er de generelt sett ikke så forskjellige. Dette er en av grunnene til den generelle forvirringen hos publikum som leter etter en grunn til at Apple går over til 64bit også på mobile enheter. Det hele kommer imidlertid fra de spesifikke parametrene til A7 (ARM64)-prosessoren og hvordan Apple bruker den, ikke bare fra det faktum at prosessoren har en 64-bits arkitektur.
Men hvis vi fortsatt ser på forskjellene mellom disse to arkitekturene, vil vi finne flere forskjeller. Den åpenbare er at 64-bits heltallsregistre kan håndtere 64-bits heltall mer effektivt. Allerede før var det mulig å jobbe med dem på 32-bits prosessorer, men dette betydde vanligvis å dele dem opp i 32-bit lange biter, noe som førte til tregere beregninger. Så en 64-bits prosessor kan vanligvis beregne med 64-bits typer like raskt som med 32-bits. Dette betyr at applikasjoner som vanligvis bruker 64-bits typer kan kjøre mye raskere på en 64-bits prosessor.
Selv om 64bit ikke påvirker den totale mengden RAM som prosessoren kan bruke, kan det gjøre det enklere å jobbe med store biter av RAM i ett program. Ethvert enkelt program som kjører på en 32-bits prosessor har bare omtrent 4 GB adresseplass. Tatt i betraktning at operativsystemet og standardbibliotekene tar opp noe, etterlater dette programmet et sted mellom 1-3 GB for applikasjonsbruk. Men hvis et 32-bits system har mer enn 4 GB RAM, er det litt mer komplisert å bruke det minnet. Vi må ty til å tvinge operativsystemet til å kartlegge disse større minnebitene for programmet vårt (minnevirtualisering), eller vi kan dele programmet opp i flere prosesser (der hver prosess igjen teoretisk sett har 4 GB minne tilgjengelig for direkte adressering).
Imidlertid er disse "hakkene" så vanskelige og trege at et minimum av applikasjoner bruker dem. I praksis, på en 32-bits prosessor, vil hvert program kun bruke sine 1-3 GB minne, og mer tilgjengelig RAM kan brukes til å kjøre flere programmer samtidig eller bruke dette minnet som en buffer (caching). Disse bruksområdene er praktiske, men vi vil gjerne at ethvert program enkelt skal kunne bruke minnebiter større enn 4 GB.
Nå kommer vi til den hyppige (faktisk feilaktige) påstanden om at uten mer enn 4 GB minne er en 64-bits arkitektur ubrukelig. Et større adresseområde er nyttig selv på et system med mindre minne. Minnetilordnede filer er et hendig verktøy der deler av filens innhold er logisk knyttet til prosessens minne uten at hele filen må lastes inn i minnet. Dermed kan systemet for eksempel gradvis behandle store filer mange ganger større enn RAM-kapasiteten. På et 32-bits system kan ikke slike store filer minnekartlegges på en pålitelig måte, mens det på et 64-bits system er en bit av kaken, takket være den mye større adresseplassen.
Den større størrelsen på pekere gir imidlertid også en stor ulempe: ellers trenger identiske programmer mer minne på en 64-bits prosessor (disse større pekere må lagres et sted). Siden pekere er en hyppig del av programmer, kan denne forskjellen belaste cachen, noe som igjen fører til at hele systemet går tregere. Så i perspektiv kan vi se at hvis vi bare endret prosessorarkitekturen til 64-bit, ville det faktisk bremse hele systemet. Så denne faktoren må balanseres av flere optimaliseringer andre steder.
ARM64
A7, 64-bits prosessoren som driver den nye iPhone 5s, er ikke bare en vanlig ARM-prosessor med bredere registre. ARM64 inneholder store forbedringer i forhold til den eldre 32-biters versjonen.
registret
ARM64 har dobbelt så mange heltallsregistre som 32-biters ARM (pass på så du ikke forveksler antall og bredde på registre - vi snakket om bredde i "64-bits"-delen. Så ARM64 har både dobbelt så brede registre og dobbelt så mange registre). 32-biters ARM har 16 heltallsregistre: en programteller (PC - inneholder nummeret til gjeldende instruksjon), en stabelpeker (en peker til en funksjon som pågår), et lenkeregister (en peker til returen etter slutten av funksjonen), og de resterende 13 er for applikasjonsbruk. Imidlertid har ARM64 32 heltallsregistre, inkludert ett nullregister, et lenkeregister, en rammepeker (lik en stabelpeker), og en reservert for fremtiden. Dette etterlater oss med 28 registre for applikasjonsbruk, mer enn det dobbelte av 32-biters ARM. Samtidig doblet ARM64 antallet flytende tallregistre (FPU) fra 16 til 32 128-biters registre.
Men hvorfor er antallet registre så viktig? Minnet er generelt tregere enn CPU-beregninger og lesing/skriving kan ta veldig lang tid. Dette ville gjøre at den raske prosessoren måtte vente på minne, og vi ville nå systemets naturlige hastighetsgrense. Prosessorer prøver å skjule dette handikappet med lag med buffere, men selv den raskeste (L1) er fortsatt tregere enn prosessorens beregning. Imidlertid er registre minneceller direkte i prosessoren og deres lesing/skriving er rask nok til å ikke bremse prosessoren. Antall registre betyr praktisk talt mengden av det raskeste minnet for prosessorberegninger, noe som i stor grad påvirker hastigheten til hele systemet.
Samtidig trenger denne hastigheten god optimaliseringsstøtte fra kompilatoren, slik at språket kan bruke disse registrene og slipper å lagre alt i det generelle applikasjonsminnet (det langsomme).
Instruksjonssett
ARM64 bringer også store endringer i instruksjonssettet. Et instruksjonssett er et sett med atomoperasjoner som en prosessor kan utføre (f.eks. 'ADD register1 register2' legger til tallene i to registre). Funksjonene som er tilgjengelige for de enkelte språkene, er sammensatt av disse instruksjonene. Mer komplekse funksjoner må utføre flere instruksjoner, slik at de kan være tregere.
Nytt i ARM64 er instruksjoner for AES-kryptering, SHA-1 og SHA-256 hash-funksjoner. Så i stedet for en kompleks implementering, vil bare språket kalle denne instruksjonen - noe som vil gi en enorm hastighet på beregningen av slike funksjoner og forhåpentligvis økt sikkerhet i applikasjoner. f.eks. den nye Touch ID bruker også disse instruksjonene i kryptering, noe som gir reell hastighet og sikkerhet (i teorien må en angriper modifisere selve prosessoren for å få tilgang til dataene - noe som er mildt sagt upraktisk gitt miniatyrstørrelsen).
Kompatibilitet med 32bit
Det er viktig å nevne at A7 kan kjøre fullt ut i 32-bits modus uten behov for emulering. Det betyr at den nye iPhone 5s kan kjøre applikasjoner kompilert på 32-biters ARM uten nedgang. Men da kan den ikke dra nytte av de nye ARM64-funksjonene, så det lønner seg alltid å lage en spesiell konstruksjon kun for A7, som skal kjøre mye raskere.
Kjøretidsendringer
Runtime er koden som legger til funksjoner til programmeringsspråket, som den kan bruke mens applikasjonen kjører, til etter oversettelsen. Siden Apple ikke trenger å opprettholde programkompatibilitet (at en 64-bits binær kjører på 32-bit), kunne de ha råd til å gjøre noen flere forbedringer til Objective-C-språket.
En av dem er den såkalte merket peker (merket indikator). Normalt lagres objekter og pekere til disse objektene i separate deler av minnet. Nye pekertyper lar imidlertid klasser med lite data lagre objekter direkte i pekeren. Dette trinnet eliminerer behovet for å allokere minne direkte for objektet, bare lag en peker og objektet inne i det. Merkede pekere støttes kun i 64-bits arkitektur også på grunn av det faktum at det ikke lenger er nok plass i en 32-bits peker til å lagre nok nyttige data. Derfor støttet ikke iOS, i motsetning til OS X, denne funksjonen ennå. Men med ankomsten av ARM64 endrer dette seg, og iOS har tatt igjen OS X i denne forbindelse også.
Selv om pekere er 64 biter lange, brukes på ARM64 bare 33 biter for pekerens egen adresse. Og hvis vi er i stand til pålitelig å demaskere resten av pekerbitene, kan vi bruke denne plassen til å lagre tilleggsdata – som i tilfellet med de nevnte merkede pekerne. Konseptuelt er dette en av de største endringene i historien til Objective-C, selv om det ikke er en funksjon som kan selges – så de fleste brukere vil ikke vite hvordan Apple beveger Objective-C fremover.
Når det gjelder de nyttige dataene som kan lagres i den gjenværende plassen til en slik tagget peker, bruker for eksempel Objective-C den til å lagre den såkalte referanseantall (antall referanser). Tidligere ble referansetellingen lagret på et annet sted i minnet, i en hashtabell utarbeidet for det, men dette kunne bremse hele systemet ved et stort antall alloc/dealloc/retain/release-anrop. Bordet måtte låses på grunn av trådsikkerhet, så referansetellingen til to objekter i to tråder kunne ikke endres samtidig. Imidlertid er denne verdien nylig satt inn i resten av den såkalte isa indikatorer. Dette er nok en upåfallende, men stor fordel og akselerasjon i fremtiden. Dette kunne imidlertid aldri oppnås i en 32-bits arkitektur.
Informasjon om tilknyttede objekter, om objektet er svakt referert, om det er nødvendig å generere en destruktor for objektet osv., er også satt inn på det gjenværende stedet for pekere til objektene. Takket være denne informasjonen er Objective-C runtime er i stand til å øke hastigheten på kjøretiden, noe som gjenspeiles i hastigheten til hver applikasjon. Fra testing betyr dette omtrent 40-50% hastighetsøkning av alle minneadministrasjonssamtaler. Bare ved å bytte til 64-bits pekere og bruke denne nye plassen.
Konklusjon
Selv om konkurrenter vil prøve å spre ideen om at det er unødvendig å flytte til en 64-bits arkitektur, vil du allerede vite at dette bare er en veldig uinformert mening. Det er sant at å bytte til 64-bit uten å tilpasse språket eller applikasjonene dine egentlig ikke betyr noe – det bremser til og med hele systemet. Men den nye A7 bruker en moderne ARM64 med et nytt instruksjonssett, og Apple har tatt seg bryet med å modernisere hele Objective-C-språket og dra nytte av de nye mulighetene – derav den lovede speedupen.
Her har vi nevnt en lang rekke grunner til at en 64-bits arkitektur er det rette skrittet fremover. Det er nok en revolusjon "under panseret", takket være hvilken Apple vil prøve å holde seg i forkant, ikke bare med design, brukergrensesnitt og rikt økosystem, men hovedsakelig med de mest moderne teknologiene på markedet.
Mange uinformerte Android/Samsung-folk bør lese denne artikkelen og deretter gjemme seg i hjørnet.
Vel, vi må synes synd på dem. I årevis unnskyldte de den tragiske UXen og brukergrensesnittet til Android ved å si at de har det mest teknologisk avanserte operativsystemet med funksjoner, og nå fant de ut at de er mange år bak igjen :)
Hvis en person ikke er en sau og lytter til reklame (og han er god til det), kan han etter personlig erfaring danne seg sin egen mening :-).
Jeg prøver nesten alle konkurransene og danner meg min egen mening.
For meg trenger jeg en ny super høyytelses mobiltelefon, fordi jeg bruker ikke mye på den. Det er Jeg trenger mindre ytelse til lavere pris ;-). Kanskje jeg foretrekker en tregere med et større batteri.
På den annen side ville den nye procaken vært nyttig for iPaden der det er mange spill :-).
Jeg er Android/HTC :) fordi DET er ganske morsomt for meg, og å rote og konvertere høykvalitets HW til en rask fighter er hobbyen min. Og iOS lar meg ikke gjøre det. (Det er ikke engang nødvendig. Mer eller mindre er iOS designet slik at alt fungerer som det skal og du trenger ikke å gjøre noe der. Når jeg slutter å spille, kjøper jeg et eple og nyter det). Men jeg vet ikke hvorfor dere fortsetter å angripe hverandre som barn. Apple er helt som Android. Det er som å sammenligne demokrati med diktatur og lignende... Jeg så konferansen da iPhone 5S ble introdusert og til tross for at jeg ikke eier noe fra Apple, likte jeg 64bit og andre forbedringer som kom. Men ikke fordi jeg er en kompleks honimír trtko som sitter bak en PC og jager Android eller Apple, men fordi jeg ser FREMGANGSMÅTEN som ikke får meg til å vente lenge. Folk burde begynne å jobbe hardt så de ikke har tid til å håndtere tull, for å si det høflig.
konstruktivt bidrag fra den andre siden :) kiez det ville åpne øynene til de resterende 99% android positive
kanskje 99 % av eplefanatikerne bør diskuteres først, så kan vi ha en konstruktiv samtale
veldig komplekse ting forklart enkelt... takk
Flott artikkel! Ja, jeg er enig i at Android/WP-brukere bør lese denne artikkelen som et must. I stedet for å trolle og snakke smart om "hvordan 64b er ubrukelig i mobiler"...
du har sannsynligvis aldri hatt en wp i hånden, ellers hadde du ikke hatt dette
Siden de første suksessene på mobilmarkedet har Samsung ikke gjort annet enn å smøre konkurrentene, men i hovedsak har de fulgt i fotsporene hele denne tiden. Apple har alltid vært et forbilde for teknologiselskaper, og hvis de kun fokuserer på å håne og stadig feilinformere kunder, vil de snart snuble. Apple har alltid gått sine egne veier og det har alltid vært et spørsmål om veldig god timing, som mange konkurrerende selskaper i bransjen mangler.
Man kan si at Samsung rir på bølgen og utnytter mulighetene. Han satset på Android, han har stor HW, han lager mange ting selv, han har grei støtte. Og som ethvert rovdyr asiatisk selskap, bruker det alle mulighetene for reklame. Og selvfølgelig stjeler og kopierer han. Det «slant-eyed» er god til er å kopiere. De har regnet veldig godt på at det er mye billigere enn å gå sin egen vei, steg for steg. Og som et sterkt selskap har det rett og slett råd til dette. Ennå…
Jeg skjønner bare ikke hvorfor hastigheten på telefonen stadig øker, gi meg noen eksempler på hva du bruker den til, det gir sakte ingen mening for meg å øke ytelsen til mobilen, men jeg skal fjerne ordet markedsføring .
Spill, dårlig optimaliserte spill. Transport Tycoon på iPad 3 kjører heller ikke like jevnt og i samme oppløsning som på skrivebordet. Eksempel.
Jeg forstår bare ikke hvorfor hastigheten på telefonen fortsetter å øke, gi meg noen eksempler på hva du bruker den til, det gir sakte ingen mening for meg å øke ytelsen til mobiltelefonen, hvis jeg fjerner ordet markedsføring fra den .
For video-, lyd- og bildebehandling. Og videre til spillene.
Alle som bruker en iPhone kun til å ringe, sende tekstmeldinger og av og til lese eller sende e-poster og av og til surfe på Internett, vil trenge en iPhone 4. Jeg tror at det er mange slike brukere. Ikke alle trenger verdens beste telefon :-)
sau
Betyr ikke den fysiske avveiningen mellom maskinvare og programvare noe for deg? Dette minner meg litt om slutten av 19-tallet, da fysikerne på den tiden sa at alt innen fysikk allerede var oppdaget og at det ikke var nødvendig å fortsette (et tiår før relativitetsteorien og tre før kvanteteorien) .
Jakten på det beste tar aldri slutt. Noen ganger fører programvaren og noen ganger maskinvaren. Men hvis den ene setter seg fast, slipper den ikke den andre. Vi vil ikke være så egoistiske mot våre etterkommere :) Så til kommentaren din - en raskere telefon vil muliggjøre kraftigere applikasjoner, som vil kunne gjøre mye mer enn å kjøre. Og en gang ting som selv dagens datamaskiner ikke er nok til. Fremtiden er spennende.
Nøyaktig :)
Fin artikkel, men jeg forstår ikke hvorfor Apple ikke la 7 GB RAM i A2. Ja, iOS multitasking er ikke slik at 2 GB ville være nødvendig, men gitt den dobbelte lengden på minnepekeren, ville det være mye mer egnet.
Men ellers er jeg enig i at en 64-bits prosessor er "unødvendig" for en mobiltelefon, akkurat som en retina-skjerm eller en optisk mus i stedet for en ball var unødvendig - alle disse oppfinnelsene ble merket som "unødvendige", men etter min mening riktig ord er "tidløs", fordi en gang må komme og Apple er ikke redd for å finne på noe nytt.
Jeg andre det. Selv "ubrukelig" er dessverre ikke et nøyaktig uttrykk. Unødvendig betyr noe hvis prioritet en person ikke vet. Det er definitivt ikke sant. Hastighet trenger kanskje ikke en slik hastighet, men den vil definitivt gjenkjenne den. Og når programvaren tar igjen maskinvaren, vil det være rom for forbedring igjen.
Jada, jeg er for, jeg mener, iP5 er egentlig en ganske rask smarttelefon, så 5S trenger ikke å være 64bit i det hele tatt. Men en dag måtte noen håndtere det igjen, og det var Apple, og det var det nå. Så lenge jeg kan huske har eksperter også snakket om hvordan 64-bits prosessorer vil være ubrukelige selv i datamaskiner.
For meg, som IT-lekmann som nesten strøk i matrikken, er konklusjonen viktig. Hele artikkelen (støttet av kommentarene) virker ganske innsiktsfull for meg, og selv om jeg ikke vil kunne forklare det, er A7 med 64-bits arkitektur et skritt fremover. Takk for informasjonen.
Jeg ville redigere tittelen på artikkelen, siden det er et markedsføringsgrep. Hver innovasjon er i hovedsak et markedsføringsgrep. :-)
Jeg tror ikke. For eksempel bruker Samsung markedsføringstiltak. De dukker opp med RAM, som iPhone ikke trenger i det hele tatt. De slipper unna med funksjoner som ikke er brukbare i det hele tatt. Deres bevisst økende prosessorytelse for tester. Etc. Det er markedsføring, selv om ja, det er misvisende, som de ikke bare bør slippe unna med ;)