64-bits Prosessorer

[Tuba.Titan]

levende celler som lagrer og prosesserer dataen er vel noe av framtiden ihvertfall etter hva jeg har hørt fra gale prossesorer på hibu

 

 

celler som kan være ladet som binærtall 1-0 og er 100 hvis ikke 1000 ganger raskere en metodene for bitstreaming idag..

[MailMan13]

For alle praktiske formål er 32 bits addressering nok, de som trenger mer bruker i utgangspunktet ikke x86 cpu'er likevel, vi som ikke simulerer atomeksplosjoner eller melder vær vil bare få større programmfiler som Zapchud sa, ingen av oss har bruk for mer enn 32bits presisjon, selv kan jeg telle på en hånd de gangene jeg virkelig har hatt bruk for double/long variable i egne programmer.

 

Det største plusset med Operton/Athlon64 er onboard minnekontroller, pluss at de har skrevet hele i686 implementasjonen helt fra scratch og fått den litt mer effektiv enn på dagens Atlhon XP, 64 bits delen kunne vert kuttet i Athlon 64 varianten uten at noen av oss hadde merket noe.

[Zapchud]

Hva med PS2's Emotion Engine? Det er en 300-og-nonn-Mhz 128bit prosessor. Eller hva med GPUene som brukes idag? De er vel på MINST 128bit ... Matrox Parhelia var vel 512bit ...

 

 

Vanlig FPU-data er idag 80bit ... som behandles av en 32bits prosessor... SSE, SSE2 er 32-bits instruksjoner som behandler 64/128bits data...

For de som lurer på ting ang. SIMD-instruksjoner, kan dere lese mer på Ars Techninca Dække alle biter som er like vettu ...

 

Alle de mer-enn-64-bits-prosessorne du snakker om er SIMD-enheter, som kalkulerer ved 64-biters floats, eller 32-biters ints. Og slik er det med alle de andre ørtogbørti-bits-CPUene også. De eksekverer et antall mindre, gjerne 64-biters operasjoner - parallelt.

 

X-bithet refererer til evnen å kunne manipulere X-biters ints (vanligvis), og/eller at GPR'ne (General Purpose Registers) lagrer X-biters data.

[ØysteinI]

Det største plusset med Operton/Athlon64 er onboard minnekontroller, pluss at de har skrevet hele i686 implementasjonen helt fra scratch og fått den litt mer effektiv enn på dagens Atlhon XP, 64 bits delen kunne vert kuttet i Athlon 64 varianten uten at noen av oss hadde merket noe.

 

AMD har IKKE IKKE IKKE skrevet om x86-delen i Hammer. Hadde de gjort det, ville ingen av dagens x86 programmer funka. Det de gjorde var å ta x86 og beholde denne (for å ha bakoverkompabilitet), samt å "legge på et ekstra 64-bits lag" uten på. x86-64 er ikke noe mer enn x86 + en 64-bit utvidelse.

 

Intels fremgangsmåte med IA64 (Itanium) var derimot slik du beskrev. De tok dagens x86 arktektur, så på dens svakheter og flaskehalser. Dernest gjorde de om alt på den måten de så mest hensiktsmessig per idag og framover. De så blant annet at kodeoptimalisering også kan gjøres på kompilatornivå. I IA64 er branch-prediction blant annet flyttet fra CPU (BP er utrolig transistorkrevende) til kompilatorene. Ved å gjøre dette, vil selve CPUene bli mindre, kjøligere og rimeligere... mens det tar lengere tid å kompilere programmene (programmene blir bare kompilert en gang, dvs når de produseres .. slik at vi forbrukere vil ikke merke noe til dette annet at prisene på CPUene blir lavere).

[MailMan13]

AMD har IKKE IKKE IKKE skrevet om x86-delen i Hammer. Hadde de gjort det, ville ingen av dagens x86 programmer funka. Det de gjorde var å ta x86 og beholde denne (for å ha bakoverkompabilitet), samt å "legge på et ekstra 64-bits lag" uten på. x86-64 er ikke noe mer enn x86 + en 64-bit utvidelse.

x86 implementasjonen i Hammer er helt ny i forhold til AthlonXP jo, de har laget en ny implementasjon, ikke en ny standard, derfor vil all programvare fungere (det er derfor det lages standarder). i686 beskriver hva, ikke hvordan, så hvordan intel eller AMD velger å implementere "add eax, ebx" er ett fett for programvaren så lenge resultatet blir at summen havner i eax eller hvordan det var (det er en stund siden jeg hadde arkitektur, men ikke så lenge siden).

 

Intel, AMD, VIA og Transmeta lager veldig forskjellige cpu'er, men alle har implementert det samme instruksjonsettet, derfor kjører de de samme programmene uten problem, men med ulik effektivitet, VIA og Transmeta har bare implementert i586 instruksjonene i sine cpu'er, men de fungerer helt greit til det meste likevel (i686 er et superset av i586)

[gittela]

Det må nevnes i kaoset her at 64 bits cpu ikke akkurat er nytt. Det hele dreier seg i hovedsak om Intel og AMD's forsøk på å komme inn på det tyngre server markedet, hvor Sun, IBM og SGI stort sett regjerer.

 

Selv 64 bits arbeidstasjoner har eksistert i mange år, men ikke på low-end nivå.

 

Dette har mye mer å si for servere enn for desktop i første omgang.

Se på Alpha'en. Knallbra maskin, men klarte ikke helt å komme inn som desktop. Desverre....

SGI og SUN har hatt 64 bits maskiner i årevis, men det er på high-end nivå.

 

 

:-)

Howard

[ØysteinI]

Det beste argumentet for å kjøpe 64-bits prosessor er når du trenger over 4GB med minne.

 

Et 64-bits system kan adressere 1TB minne og 32-bits sytemet kan adressere 4 GB.

 

En viktig, men lite kjent grunn til at 64-bit faktisk trengs idag er for å adressere virtuelt minne. Med virtuelt minne menes IKKE den swapingen Windows gjør mot harddisken, men heller det ikke-eksisterende adresseområdet som prosesser blir lurt til å tro at er der. Når en prosess/program startes av et OS idag (uavhengig hvilket) blir det tildelt et adresseområde på en viss mengde bytes i et "virtuelt" minneområde. Dette området trenger ikke backes opp av like mye fysisk minne, da dagens OS kontinuerlig vil oversette mellom "lizzom-minne" og virkelig minne. Prosessene som kjører derimot vil leve i den lykkelige troen på at det faktisk er 4GB minne tilgjengelig i systemet.

 

Hva har så dette med 64-bits prosessorer? Jo ... for at dette med virtuelt minne skal virke effektivt, er maskinen avhengig av at det er mye mer virtuelt minne enn det er fysisk minne. Hvorfor? ... Jo, fordi når prosesser skal plassere store datamenger, f.eks store ukomprimerte bilder i Photoshop, i minnet er den avhengig av at det er store nok sammenhengene minneområder i det virtuelle adresseområdet for at det skal funke. Men etterhvert som prosesser starter opp og legger opp minne, vil man oppleve at det ligger bytes og bits overalt i minnet slik det skjer med en harddisk over tid. Den blir fragmentert.

 

Uheldigvis for minne, så går det ikke ann å kjøre en defragmenterer som rydder opp. Eneste måten er å stenge av nok prosesser til at det blir et sammenhengende adresseområdet som er stort nok til å få plass til hele datasettet. For å motvirke dette, kan vi øke størrelsen på dette området slik at det blir mye større sannsynlig at vi hele tiden har store nok sammenhengende områder.

 

Som en analogi til dette kan vi bruke følgende: la oss si at du skal plassere en kasse på 2mx2m på jorder. Kassene må stå rett på bakken, dvs at det kan ikke være noen store steiner innenfor de 4kvadratmeterne som kassen tar. Hvis det er 100 steiner spredt vilkårlig på begge jordene, men jorde nummer 2 er 4x så stort. Det vil da være større sannsynlig at vi kan sette ned kassen på jorde nummer 2 enn nummer 1. (Kanskje en dårlig analogi, men det er sent på kvelden.)

 

For å summere opp; vi trenger større virtuelle adresseområder før vi når den berømmelige grensen på 4GB fysisk minne. Det er det 64-bits prosessorer kan hjelpe oss med.

 

Mer detaljer kan dere lese hos Chip Architect under avsnittet "The need for 64 bit processing: Closer than you think." Jeg tar forbehold om at enkelte detaljer kan være veldig overfladisk forklart, samt at jeg er rimelig trøtt. Skal ikke nekte for at enkelte "bugs" kan oppstå