64bit – evolution eller revolution?

Hmm. Det hjalp lidt på det. Nu er jeg nogenlunde med.

and the CPU could use 4bit numbers when addressing the memory blocks. In other words, the instructions working with integers could use the values lying between -63 and 64. Well, this is too little for any arithmetic operation, don’t you think so?

Tjaaa... De har tilsyneladende ikke rigtigt styr på det! :)

Men bortset fra det er det en ganske udemærket og ikke for teknisk artikel - men for folk der vil have lidt mere teknik, vil jeg nok anbefale andre artikler! :)

Side 2 er da også 50% vrøvl. Den er propfyldt med fejl:

- Det er IKKE sjældent at der kan udføres mere end en instruktion parallelt. Det hedder pairing, virtualle registre og out-of-order execution.

- Det er noget vrøvl, at det er "physical reasons" der gør at "dataen ikke ligger tæt på ALU'en". Det har mere noget at gøre med, at arkitekturen gør, at tal kun kan behandles når de ligger i et register, og ikke i cache.

- Deres afsnit om float giver slet ingen mening. "The numbers are stored and processed in a special internal format with 80bit representation." - og hvad så - det betyder da en del om de bliver gemt som 32 eller 64 bit!!?!

Side 3:

- "Well, this is about it. It is pretty hard to think even of a workstation that might need more than 4GB of memory.". Ja - 512MB var jeg også helt sikker på jeg aldrig fik brug for. ;)

Side 4: (Sidste afsnit) Ja - men hvor smart er det, at alt kode skal kompileres specifikt til hver CPU der kommer? Når processoren ikke selv er i stand til at rykke koden rundt, så den er hurtigst, vil det betyde at al kode skal rekompileres hver gang der bliver ændret i CPU'en. Smart, eh?

Side 6: Han har da vist glemt alt om, at AMD fordobler _antallet_ af registre - og ikke bare størrelsen. Flot! Især når der er en illustration af det på side 7. ;/

Side 7: Jeg kan godt se han ikke regner med at købe nyt RAM foreløbigt, når han bitcher over, at koden kommer til at fylde 10% (ja _HELE_ 10%!!!).


... Jeg er sgu bange for jeg har misforstået noget - sådan en rodet og u-gennemarbejdet artikel har jeg da sjældent set før.

Nogen af pointerne er dog udemærkede, men næppe overraskende:

- At det vil tage tid før vi kan udnytte 64 bit.
- At Athlon64 er en god løsning, fordi den kører 32bit hurtigt, og samtidig har mulighed for at køre 64bit programmer efterhånden som de dukker op.

#3:

Ja - der var flere fejl, men jeg pastede bare den mest åbenlyse! Du flueknepper imo - artiklen er IKKE skrevet til "din type" :o)

Og så indeholder din egen forklaringer en del fejl - du lader ikke til at forstå floats... :o)

Og så har du tydeligvis kun skimmet artiklen - ikke læst den... :)

#3: Enlighten me. :)

Der er også et lille historieproblem - det ser ud til at være gået meget hurtigt med den artikel.

Det der gør første generation af AMD64 ret speciel er at Intels gamle tradition er brudt. Hver gang da det var Intel der udvidede "bitbredden" var processorene optimeret til den gamle "bitbredde" og havde meget groft sagt understøttelse af den nye, men ikke nogen speciel opsigtsvækkende ydelse. Opteron/Athlon64 derimod er tilsyneladende fremragende til at afvikle 64-bit kode, hvilket kan blive et stort plus.

#6:

Du mener altså ikke at der var særlig stor forskel på 286->386(som er det eneste "bitbredde" forøgelse intel har foretaget i "nyere tid")

#7 IMO havde 386'eren 32-bit understøttelse og ikke ret meget andet, det samme med i486'eren, og Pentium haætede. Det var først med med PentiumPro at der dukkede en 32-bit optimeret Intel processor op. AMD/nexGen lagde hårdt ud med en 32-bit optimeret K6'er, Cyrix 6x86 var 16-bit optimeret og Winchip'en var optimeret alt efter de mest brugte instruktioner under MS-Windows.

Dengang gjorde man ikke meget ud af 32-bit heltal (OS/2, Linux of de andre brødre var først her) og flydende kommatal (Mener at det var Quake der var den første FP misbruger, eller dvs man brugte registrene i FPU'en til nærlager - ellers var det heltalsinstruktioner), fordi man rent softwaremæssigt ikke lagde så meget vægt på dette.