Vad innebär 64-bitar

64-bitarsprocessorer kan göra beräkningar med 64-bitarstal helt enkelt. Addition, multiplikation o s v. Det gör skillnad i alla möjliga program, vetenskap, spel, vissa komprimeringsalgoritmer, o s v. Så kan de adressera mer minne eftersom de har längre minnesadresser. 32 bitar räcker i praktiken bara till 4 gig minne.

Testa att läsa den här artikeln: Flest bitar när han dör vinner

Och det spelar vad för roll?

Förutom att artikeln var barnslig och innehåller felaktigheter vid första ögonkastet (8086/88 är 16-bitarsprocessorer) så är givetvis nyttan med 64 bitar samma då som nu. Ja, det hade varit samma nytta även för 2000 år sedan om de haft datorer...

Näe, och tur är väl det. Jag hittar bara fler fel då. Och vad har det med min poäng att göra, att 64 bitar är samma sak 2001 som 2006?

Här är ett längre citat, inklusive det avsnitt du hänvisar till:

...medans CPU:er som 8088:an såg ordentligt 8-bitars ut på insidan, men hade ändå möjlighet att adressera 20-bitar externt (1024k) Det som jag placerat under kategorin 16-bitars CPU:er är ju dessa hybrider som var varken det ena eller det andra. Jag stötte aldrig på någon CPU som jag upplevde som ren 16-bitars.

Va? 8088 är, argh igen, 16-bitars "på insidan". Vilken "sida" skulle man annars räkna? Vidare har ju adressbussen mycket sällan samma ordlängd som processorn i sig. Hade artikelförfattaren problematiserat det minsta hade han ju kunnat berätta om hur adresseringen på x86 går till; som en direkt effekt av arkitekturen och ordlängden om 16 bitar, delades minnet upp i 64 kB-block, var och ett adresserbart med 16 bitar. Två "överlappande" adresser om 16 bitar förekommer, varvid adressformatet var NNNN:NNNN (h) där den första adressen är segmentet. Segmenten överlappar varandra, så att dessa börjar med 256 bytes mellanrumm. För att adressera 256 bytes, krävs 8 bitar. Som effekt hade 8086/88 alltså 20 adressbitar (16 + 8) och kunde således adressera 1024 kB, trots att adressrymden skenbart var 2*16 = 32 bitar.

Detta är själva essensen i den klassiska "1024"- eller "640"-kB-gränsen.

Att 8088 skulle vara "8-bitars" på insidan är helt fel. Att artikelförfattaren inte tycker sig ha stött på någon "ren" 16-bitarsprocessor beror ju bara på att han inte har en aning om vad det är. Edit: Exakt samma sak gäller 68008. Den är 32-bitars, inte 16.

Det finns en och endast en definition på ordlängden: Bredden på ackumulatorn. Givetvis har moderna processorer ingen ensam ackumulator, utan flera generella register. Hursomhelst är det denna ordlängd som talar om huruvida processorn är 8-, 16-, 32-, 64- eller femtioelva-bitars. Även om den så har seriella 1-bitarsportar! (Resonemanget behöver justeras för s.k. bitseriella processorer, men det är något så exotiskt och gammalmodigt att vi inte behöver ta upp det här. Vi struntar också prompt i bitslice-prollar.)

Dessutom: I princip alla 8-bitarsprollar som någonsin dykt upp i hela datorsystem har _givetvis_ en adressbuss som är större än 8 bitar! Annars hade Commodore 64 hetat "Commodore 0,25".

Det räckte alltså att skumma genom artikeln för att finna fel. Vill du att jag lusläser den?

Men, åter, poängen var ju en helt annan: Åldern på en artikel om processorer av ordlängden N spelar mindre roll än N självt. Som nybörjarartikel om 64 bitar har den kanske ett syfte, även om jag börjar tvivla...

Nåja, tillbaka till huvudämnet: 64-bitar, visst, mer prestanda men det finns nästan ingenting ute nu som som drar nån nytta av det. Och trots att man kan köpa XP 64-bit i affären har jag varit i kontakt med flera som har rätt mycket problem med den.

Vill man chansa och vara betatestare köper man väl 64-bits XP nu annars väntar man.

Din 64-bitars laptop lär fungera alldeles utmärkt med det 32-bitars Windows den kommer med. Och det är väl en AMD processor i den då o antagligen ganska bra grafikkort så den duger finfint oavsett vilket.

Schysst julklapp!

Har sett 4 gångers prestandaökning i packningsprogram. det varierar kraftigt. Och man har ju inte riktigt lärt sig få ut kraften ur det ännu. Men det kommer.

En 32bitars processor kan arbeta med tal upp till 4294967296 på en gång. Större tal får den dela upp i fler beräkningar. Medans 64 bitars processorer kan räkna på tal upp till 18446744073709551616 på en gång. Så det är viss skillnad när du kör stora beräkningar om du jämför.

256 <--- 8 bit.
65536 <--- 16 bit.
4294967296 <-- 32 bit.
18446744073709551616 <... 64 bit.

MBY, tack för hjälpen!

Det går bra att räkna med 64-bitars tal i 32-bitars Windows XP. Moderna processorer har nämligen tilläget SSE2.

Och SSE2 används väl enbart till vissa flyttalsberäkningar eller? Och har man inte SSE2 så kör man dom på FPUn. Som om jag inte minns fel är 80bitars. Så man kan räkna 80 bitars tal i Win Xp också. Bara det är FPU-beräkningar.

Och vill man kan man räknna 8000 bitars tal också. Tar bara lite längre tid.

SSE2 kan köra heltal också. Läs här:

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

Jo, det visste jag inte. Men det gäller ju bara vissa fall man kan utnyttja SSE2 på det sättet. Knappast så att det ersätter funktionaliteten hos en 64bitasrsprocessor.

"Stora beräkningar"? Vad är det?

Stora tal är betydligt sällsyntare än låga tal. Inkrementation är vanligare än addition, som är vanligare än multiplikation.

Sannolikheten för att din beräkning innehåller ett tal som inte ryms i 32 bitar är betydligt lägre än att talet inte ryms i säg 8 bitar.

Ändå är 64 bitar i vissa applikationer snabbare än 32 bitar. Men det beror inte direkt på att man kan ha större tal, utan på att man kan ha flera mindre. När man manipulerar strängar eller gör någon annan operation där talens vikt är godtycklig, så tjänar man på större ordlängd. För stegvariabeln i en loop, är det alltsom oftast skit samma om den är 16, 32 eller 64 bitar.

Dessutom: "Stora tal" är nästan alltid förknippade med flyttal, som fungerar på ett helt annorlunda sätt. Då avgör bitarna snarare precision än storlek (även om man vanligen kodar så att större precision även medför större absoluta talområde).

MBY - Gillar att äga

Misstänkte att du skulle han invändningar.
Men du är ju Gurun här så jag säger inte emot.
Men när du säger att man kan köra flera mindre på en gång, menar du då att man kanske kan köra 8st 8Bitars tal i en 64bitars ALU på en gång? Medans man bara kan köra 4 på en 32bitars?

Ja, ungefär. Fast det kräver specialinstruktioner och flera carryflaggor. I praktiken, på x86, nej. Däremot kan man ju använda SIMD (det är därför det finns). Då kan vi mer eller minde (pseudo-)parallellbearbeta flera tal. Ju mindre tal(bitar) desto snabbare. Ju större ordlängd i CPU, desto snabbare (naturligtvis inte linjärt i något 1:1-förhållande).

Däremot kan man skyffla 8 st 8-bitarswhatever (tal, bytes) åt gången. Vad talen representerar är upp till applikationen. Jag vet inte hur många exekveringsenheter de nya x86-64-prollarna har, men vi kan ju alltid tänka oss att två på varandra följande 32-bitarsadditioner tack vare pipelining och flera exekveringsenheter går snabbare än två 64-bitarsdito.

Vill man köra samma operation på mycket data så använder man ju SIMD, som det talas om i tid och otid här på forumet (SSE, MMX, 3DNow, etc).

Edit: Btw, MMX är också för integers, heltal. Exklusivt.

OKie. Så det borde vara ganska enkelt att få ut kraften ur 64bitars då?

Men det kräver väl någon form av parallelism i koden. Nja inte riktigt det jag söker men du är smart men du förstår säkert vad jag menar.

Lätt? Nja. Ungefär lika "svårt" som att få ut kraften ur 32 bitar eller 16. Skillnaden är bara att ju gynsamma fall (data som är 64 bitar, etc) inträffar alltmer sällan, ju bredare ordlängden är.

Parallellism har varit "hett" i 40 år utan att man egentligen kommit någon vart så länge inte problemet som ska lösas är parallellt till sin natur. SIMD, t.ex. Många problem kan ej heller förutsägas av kompilatorn, varvid det är programmeraren som måste strukturera upp sitt problem.

Notera att längre ordlängd inte har något att göra med parallellism. Vi kan göra en 1024-bitarsprocessor utan att den för den sakens skull är mer "parallell". Likaså, finns 16-bitarsprocessorer som har ett visst mått av parallellism i sig.

Man ska givetvis inte misströsta. 64 bitar är välkommet inom flera områden. Långa register är något bra i sig - speciellt om man kan dela upp dem i mindre snuttar (16, 32) - vilket man kan. Det innebär inte nödvändigtvis att man kan addera två tal med två olika operander som befinner sig i samma register samtidigt, men det spelar mindre roll.

64 bitar får vi gissningsvis leva med mycket länge. Längre än vad vi levt med 32 bitar för persondatorer (386, 68000, etc). Dels finns inget uppenbart nästa steg (80, 128, 256?), dels finns inget uppenbart behov. Behovet då som nu som framtiden gäller ju generell prestanda, dvs snabbare (eller flera) processorer snarare än bredare dito. Däremot finns ju alltid specialområden som alltid behöver längre ordlängd. Kryptering är ett sådant, och det skulle där vara mumma med en 2048-bitarsprocessor.

Playstation 2 använder ju 128 BIT , är det därför inte PS2 spelen flyter optimalt PS2 Emulatorer i datorn? , eftersom datan (winxp) bara hanterar 32bit?

PS2 har bara en vanlig 64 bitars CPU (rätta mig gärna!:)) det är nått annat i PS2 som är 128 bitars... Men det är inte en 128 bitars CPU!

Edit!
PS2 Spelen är optimerad för att funka utan ett OS som stör! På en dator har du ju ett OS som drar massa kraft hela tiden!

okey ,för jag drömmer om att en gång kunna lira t.ex GRan turismo 4 helt optimalt på en PC

Att emulering inte är smärtfritt har inget med ordlängden att göra, utan beror på att det är skillnader i arkitektur. Såvida värddatorn inte är våldsamt mycket snabbare än det system som emuleras, så kommer alltid prestandaproblem att uppstå. Även om man får upp en genomsnittlig exekveringshastighet likt originalet, kommer man ändå ha svårt att nå momentant samma prestanda.

Edit: I korthet, på ren svenska: Det hackar när man emulerar.