64-bit avmystifisert

[martiol]

Mente at prosessorene til AMD var smarte nok til å skjønne at de kommer to sett med 32 bits tall som skal adderes etterhverandre, og dermed la alle fire 32 bits tallene inn i øvre og nedre del av 64bit, og regnet dem sammen i en operasjon. Mulig jeg husker helt feil her, men i teorien er det jo godt mulig å gjøre det slik... både AND, OR, XOR, NOT, ADD, SUB og andre ganske trivielle operasjoner kan jo utmerket godt utføres samtidig så lenge man plukker opp "mente" mellom bit 31 og 32. Dersom det jeg sier nå er riktig, så stemmer ikke det som står i artikkelen om at 32bits tall bare blir stuffa med nuller for å gjøre det til 64bit i prosessoren...

 

Noen som vet dette helt sikkert?

 

-Ko_deZ-

Det er nok ikke så enkelt. En regneoperasjon i 64-bit mode bruker en fysisk koblet alu som er 64-bit. Den kan ikke dele opp regestykket. I 32-bit mode får man bare tilgang til halve den ALUen.

 

Det du er inne på har vel med registerene å gjøre. For å fylle et 64- bit register bruker man 2x32bit eller 4x16bit (ja 16 bit henger ennå med). Det er akkurat som i 32 bit prosessor hvor det er 2x16 bit.

For at det ikke skulle bli halvparten så mange registre har man lagt til noen 64bit spesifikke registre, akkurat det som ble gjort nå 32bit kom.

Det er hovedsakelig nytt instruksjonssett som er mer risk likt og mer moderne, som fører til ytelsesøkninger.

 

Forøvrig var alt det som sto på side 2 helt uinterresant siden man kan bruke FPUen. Har artikkelforfatteren helt glemt det? Det var derfor man innførte FPUen, for å kunne regne med store tall (på bekostning av presisjon da...). Hele greie med å regne med større integere er nesten litt uinterresang.

[magnusr]

Hei var det ikke noe feil i det regnestykket med hvor mye ram en 64 bits cpu kan adresse?

 

32 bit = 4294967296 = ca 4,3GB

40 bit (amd64 har dette i minne register)= 1099511627776 = ca 1,1tb

64 bit = 18446744073709551616 = ca 18,44EB (exabyte)

 

Skulle vel stemme hvis prossesoren kunne adresse like mange byte som den har bit da blir det vel 2^64?

[Joggi]

"Kanskje" kommer t 64bit os iløpet av året.

OS for 64bit har det finnes leeenge. OS for prosessorene omtalt her, har vært ute i allefall et år... (Har et Opteron-cluster på jobben som kjører Red Hat 64bit). Tenker du dermed på Windows, er det ikke helt ute i offisiell versjon enda nei...

jeg sa bare at det ikke finnes os for 64 bit i handelen men nevnte også at det finnes i diverse betaversjoner

 

men jo det finnes vel linuxbaserte OS og sikkert flere som støtter 64 bit systemer, men vi lever i en microsoft verden og jeg snakker da om hva som er vanlig å bruke for de fleste av oss

[zadu]

er helt enig med CFD, 2.5ganger så stor swap som ram er ikke riktig.

har du 4gig ram trenger du mest sansynlig nesten ingen swap i det hele tatt, har du bare 128mb kommer behovet for en swap fil.

 

men når alt kommer til alt, spørs det jo hva pc'n blir brukt til...

[stiantq]

Jeg har (nesten) bare gode erfaringer med win64 (v.1218). Stabilit som et gjennomsnittlig fjell, og jeg har alle driverne jeg trenger.

Det eneste jeg savner er daemon, men det er visst på god vei det og

[Elendil]

Interresant.

[Del]

Takker for flott artikkel, hvor du presiserte at det ikke var for data-eksperter. Likevel er det etter min mening umulig gi et godt bilde av 64-bit uten å skille mellom floating point (tall på vitenskapelig notasjon, med komma og multiplisert med en tier potens) og integer (heltall). Det er her mye av misforståelsene ligger. Så fakta:

 

1. Lengden på floating er uforandret på AMD64 (fra XP serien). FPU ble nevnt av en, og er verdt å sjekke opp her. D.v.s at til vanlige flyttalls beregninger (hvilket gjelder de aller fleste beregningsprogrammer) er det ingen forskjell.

2. Lengden på integer er doblet, hvilket betyr potensiell dobling av hastigheten på integer operasjoner.

3. Minne adressering tillater å kjøre programmer som krever mer enn 4GB (hvilket var meget godt forklart i artikkelen).

 

Ytelses endringen fra 32-bit til 64-bit avhenger av hvor integer intensivt programmet ditt er. Dette sees i linux på database program, som er dominert av integer operasjoner, og hvor ytelsesforbedringen er dramatisk. Divx kjenner jeg ikke koden til i detalj, men jeg vil anta at den er basert på en Fourier transform som jpeg er, d.v.s. en del flyttalls beregninger. Det kan antagelig forklare hvorfor du får kun 20% ytelsesøkning.

 

Når det gjelder EM64T har jeg enda ikke sett svart på hvitt hvorvidt denne har doblet lengden på integer, men det virker slik.

[BolleKalle]

Etter at 64-bits-prosessorer har kommet på markedet har det oppstått en rekke misforståelser. I denne artikkelen gjennomgår vi de grunnleggende forskjellene mellom 32- og 64-bits prosessorer.

 

<a href="http://hardware.no/art.php?artikkelid=12781">Les artikkelen her

Jeg vil først påpeke at den regelen med 2.5 ganger så stor swapfile er noe tull!

2.5ganger mengden du har med ram er en gammel regel og den var selv feil da den ble "laget". dessverre er det mange som BASTANT PÅSTÅR at 2.5 fortsatt er riktig. Jeg har fått pepper for å nevne dette flere steder ifra personer som alltid har hørt og regnet med at 2.5xRam er riktig.

 

Reglen var relativt riktig da den ble laget ,men det var da vi satt med 4mb ram og 386. Dagens maskiner som ofte har 512-1024mb ram så blir det mer komplisert.

 

Den beste måten å regne ut din pagefil er å starte mange aplikasjoner som spill og programmer som du vanligvis bruker samtidig også sjekket hva peakverdiene er i taskmanager. Har du en peakverdi på 620MB kan det være lurt å velge 700MB være en god verdi.

 

Håper du kan rette dette i artikkelen din =)

Windows anbefaler 1.5 ganger størrelsen av ram til SWAP, hvor 2.5 er kommet fra er jeg ikke sikker på. Det var da en voldsom stor swapfil da i tilfelle...

[Del]

Apropos SWAP fil: Størrelsen på denne avhenger helt av hva du har tenkt å gjøre. Med 32-bit CPU er det ingen hensikt å ha mer enn 4GB til sammen (ram+swap), hvis du har 64-bit er det alt etter behov. F.eks. hvis du har en serie bilder du ønsker å lage en animasjon av, og koden må ha alt opp i minnet samtidig for å lage animasjonen, kan det hende du trenger 64GB (ram+swap). Altså, hvor stor swap fil du trenger er helt avhengig hva du skal gjøre på maskinen.

[Dr_VingTor]

Forøvrig var alt det som sto på side 2 helt uinteressant siden man kan bruke FPUen. Har artikkelforfatteren helt glemt det? Det var derfor man innførte FPUen, for å kunne regne med store tall (på bekostning av presisjon da...). Hele greie med å regne med større integere er nesten litt urinterresang.

 

nå... flere bit gir større presisjon i FP også da, presisjon er viktig i mange sammenhenger... og en kan angi større FP-tall...

og hvis du mener at heltall (int.) som er for store skal konverteres først til FP for så å regne ut så er jo ikke det en bra løsning heller da, bruker jo en del tid på konvertering, og en må sikkert konvertere tilbake etterpå, i tillegg til at en mister mye informasjon/presisjon i konverteringen...

 

synes det som sto var bra, selv om jeg synes talleksemplene kunne vært litt bedre, kunne brukt tall som var større enn 32 bit og hvis hvordan forskjellen ble med det... men det blir kanskje litt for omfattende etter vert...

 

noen som vet hvordan arkitekturen i 64 bits prosessorene er?

en foreleser jeg hadde i høst sa at P4 var en RISC prosessor som tok CISC instruksjoner og konverterte de til RISC for så å bli utført, er vell kanskje noe likt i disse også siden de må være bakoverkompatibel med eldre programvare…

 

(men som jeg lærte i høst, så er det mye som spiller inn på ytelsen til en CPU, og siden jeg ikke vet noe spesifikt om arkitekturen til disse prosessorene skal jeg ikke påstå noe mer...)

[snorreh]

DesertGlow: Fin artikkel, men du glemmer dessverre å nevne at AMD64-arkitekturen faktisk dobler antall dediserte registre (GPR) fra 8 stk. i 32-bit (x86/IA32) til 16 stk. i 64-bit (x86-64/AMD64). 8 stk. nye 128-bit SSE-registre er også lagt til, samt 64-bits utvidelser av registrene for flagg og instruksjonspekere (se vedlagt bilde). Dette betyr utvilsomt bedre ytelse på det aller meste. Til forskjell så har ikke de fleste andre arkitekturene som har gått fra 32-bit til 64-bit øket antall registre (f.eks. Power, SPARC, PA-RISC).

 

For mer om dette så anbefaler jeg at du ser litt på dette:

http://www.devx.com/amd/Article/16101

http://www.cpuid.com/K8/index.php

Endret 12. januar 2005 av snorreh

[snorreh]

Jeg tror at mye av utfordringen med amd64 vil ligge i kompilatorer. Hvis de greier å utnytte større registre og ALU til å prosessere også 8- og 16-bit data uten at store deler av arealet blir ubrukt, tror jeg vi har no bra.

Ja, samt 16 og 8 bytes heltalls dataoperasjoner i 64-bit mot bare 4 og 2 bytes i 32-bit som nå. Kompilatorene har lenge vært i beta, men har bedret seg kraftig den senere tiden og flere er nå ganske modne og yter bra. Microsoft sin er f.eks. gratis tilgjengelig.

[snorreh]

Bra artikkel men sto igjen med 1 spørsmål, som Mad Wolf Magnux allerede har spurt om:

 

Det står i artikkelen slik jeg forstår det at 32bit-programmer som jobber med verdier høyere enn 4,3 mrd vil få utbytte av 64bit-prosessorer, men må OS'et også være 64bit da?

 

Noen som kan svare på dette?

64-bits programmer vil ikke kjøre på et 32-bits operativystem (legacy mode) for de krever et 64-bits operativsystem (64-bit mode), men et 64-bit operativsystem kan også kjøre 32-bits programmer (compatibility mode). Et eksempel på dette er Windows x64 som benytter seg av WOW64 (Windows-32-on-Windows-64) som du kan lese mer om hvordan fungerer her:

http://en.wikipedia.org/wiki/WOW64

 

Se også dette for en litt enklere forklaring:

http://www.gamepc.com/labs/view_content.as...=amd64xp&page=4

Endret 12. januar 2005 av snorreh

[Simen1]

Forresten: Kan ikke programmereren/kompilatoren slå sammen 2 parallelle 32bit add til en 64bit add dersom programmereren på forhånd vet at begge 32bit verdiene aldri vil overstige 2^31-1 ?

 

evt. 4 stk 16bit verdier under samme forutsetning?

 

Jeg tror det går og da vil det jo fungere på en lignende måte om noen add-instruksjoner i SIMD (3DNow!, MMX, SSE).

[Gunnar_]

Fin artikkel, men du glemmer dessverre å nevne at AMD64-arkitekturen faktisk dobler antall dediserte registre (GPR) fra 8 stk. i 32-bit (x86/IA32) til 16 stk. i 64-bit (x86-64/AMD64).  8 stk. nye 128-bit SSE-registre er også lagt til, samt 64-bits utvidelser av registrene for flagg og instruksjonspekere (se vedlagt bilde). Til forskjell så har ikke de fleste andre arkitekturene som har gått fra 32-bit til 64-bit øket antall registre (f.eks. Power, SPARC, PA-RISC).

Jeg tror ikke han glemte det nei, fordi poenget med artikkelen var ikke å forklare forskjellen på K7 og K8. Det finnes flere prosessorer her i verden vet du.

 

Og når det gjelder Power/SPARC osv så økte vel de ikke antall registre fordi de allerede har mange ganger flere registre enn x86 noen gang vil ha. (ikke 100% sikker på om dette gjelder alle)

Endret 12. januar 2005 av Gunnar_

[snorreh]

Mente at prosessorene til AMD var smarte nok til å skjønne at de kommer to sett med 32 bits tall som skal adderes etterhverandre, og dermed la alle fire 32 bits tallene inn i øvre og nedre del av 64bit, og regnet dem sammen i en operasjon. Mulig jeg husker helt feil her, men i teorien er det jo godt mulig å gjøre det slik... både AND, OR, XOR, NOT, ADD, SUB og andre ganske trivielle operasjoner kan jo utmerket godt utføres samtidig så lenge man plukker opp "mente" mellom bit 31 og 32. Dersom det jeg sier nå er riktig, så stemmer ikke det som står i artikkelen om at 32bits tall bare blir stuffa med nuller for å gjøre det til 64bit i prosessoren...

 

Noen som vet dette helt sikkert?

Ja, det er ikke noe problem. så lenge man lagrer svaret i et 64-bits register. Fordelen med 64-bit sånn sett er at man kan jobbe med dobbelt så mange heltall som i 32-bit, men den store ytelsesforbedringen får man først når man jobber bare med 64-bits tall.

[snorreh]

Forøvrig var alt det som sto på side 2 helt uinterresant siden man kan bruke FPUen. Har artikkelforfatteren helt glemt det? Det var derfor man innførte FPUen, for å kunne regne med store tall (på bekostning av presisjon da...). Hele greie med å regne med større integere er nesten litt uinterresang.

Tja, ikke glem at man i 64-bit kan jobbe med dobbelt så mange heltall som flytetall om gangen da og det er langt ifra uinteressant vil jeg tørre å påstå

[snorreh]

Jeg tror ikke han glemte det nei, fordi poenget med artikkelen var ikke å forklare forskjellen på K7 og K8. Det finnes flere prosessorer her i verden vet du.

Det virker på meg som han glemte det jo, og dobling i antall registre er en vesentlig forbedring iforhold til 32-bits x86-prosessorer mhp. bedre ytelse. Spesielt doblingen av antallet 128-bits SSE-registre vil ha en stor ytelsesgevinst på spill, audio/video-enkoding osv.

 

Og når det gjelder Power/SPARC osv så økte vel de ikke antall registre fordi de allerede har mange ganger flere registre enn x86 noen gang vil ha. (ikke 100% sikker på om dette gjelder alle)

Stemmer det (de har 32 stk), og det forklarer også hvorfor disse arkitekturene ikke fikk noen særlig ytelsesgevinst ved overgangen fra 32-bit til 64-bit. For x86 så er en dobling i antall registre rett og slett en enorm forbedring spesielt mhp. bedre ytelse i 64-bit.

Endret 12. januar 2005 av snorreh

[Det Dvergiske Kaffebord]

Finfin artikkel. Den var akkuratt passe for oss som har sånn passe med kunnskap.

[Del]

Forresten: Kan ikke programmereren/kompilatoren slå sammen 2 parallelle 32bit add til en 64bit add dersom programmereren på forhånd vet at begge 32bit verdiene aldri vil overstige 2^31-1 ?

 

evt. 4 stk 16bit verdier under samme forutsetning?

 

Jeg tror det går og da vil det jo fungere på en lignende måte om noen add-instruksjoner i SIMD (3DNow!, MMX, SSE).

Absolutt, så det er ikke noe problem å utnytte alle bit'ene dersom problemet lar seg parallellisere. For det du egentlig foreslår er vel å gjøre to eller flere operasjoner i slengen. Dette går fint dersom ikke den ene opersjonen trenger svaret fra den andre. Skulle ikke vært veldig vanskelig å sette opp en Turing maskin som gjør det.

 

Kompilatorer er et viktig poeng. Jeg har inntrykk av at linux fortsatt har et godt stykke igjen før koden er optimalisert for AMD64. Hvis man ønsker å sjekke ut state-of-the art kompilatorer for AMD64 er Pathscale sin pakke ledende. Den kanskje mest utbredte pakken er likevel PGI workstation (p.g.a. rimelig stiv pris på pathscale). Ytelsen øker dramatisk sammenlignet med gcc. Drømmen for linux tilhengere måtte vel være å kompilere hele ditribusjonen med pathscale (det er ihvertfall en av mine drømmer).