Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 33, views: 851 •
Bron: Ars Technica, submitter: T.T.

De heren van Ars Technica hebben een artikel on line gezet waarin wordt uitgelegd hoe een 64-bit processor werkt. Daarbij wordt verteld welke extra verbeteringen er naast de 64-bit techniek zijn doorgevoerd in AMD's x86-64-platform. Als eerste wordt de vraag behandeld wat een 64-bit processor precies is. Het komt erop neer dat er ook met 64-bit integers gewerkt kan worden, zonder dat deze eerst moeten worden opgedeeld in twee 32-bit integers. Geheugenadressen zijn ook integers, dus er kan in plaats van vier gigabyte nu theoretisch achttien miljoen terabyte geadresseerd worden. Alleen integers worden 64-bit, floating-pointgetallen waren al 64-bit en vectorgetallen blijven 128-bit.

AMD Opteron chipEen 64-bit processor is niet in staat om 32 of 16-bit code uit te voeren. Omdat vrijwel alle software voor het x86-platform 32-bit is, kunnen de x86-64-processors van AMD in twee modi werken. De eerste modus is legacy mode: de processor wordt aangestuurd door een 32-bit besturingssysteem en gedraagt zich als een normale Athlon-processor. De tweede modus is long mode, de processor wordt nu aangestuurd door een 64-bit besturingssysteem. Dit besturingssysteem is in staat om zowel 64 als 32-bit applicaties uit te voeren.

Een 64-bit chip heeft dus twee voordelen: er kan meer geheugen geadresseerd worden en 64-bit operaties worden sneller uitgevoerd. Een gemiddelde desktopcomputer heeft deze mogelijkheden nog niet nodig. Een geheugen van 512MB is nog meer dan genoeg en 64-bit operaties worden eigenlijk alleen bij encryptie en wiskundige pakketten gebruikt. Daarom heeft AMD ook enkele wijzigingen doorgevoerd om de prestaties van de processor te verbeteren. Zo is de geheugencontroller aanwezig op de CPU zelf, bevat de processor meer L2 cache en zijn er in long mode twee keer zoveel registers beschikbaar. Om daar plek voor vrij te maken zijn segmented memory en ondersteuning voor real mode en virtual-8086 mode in long mode geschrapt. Dat dit alles de prestaties ten goede komt, blijkt wel uit het volgende:

AMD Opteron logoEven more relevant is the release of the new x86-64 port of the Counter-Strike server software. Counter-Strike (or CS, as it's commonly called) is far and away the most successful online shooter in recent memory, and the CS team claims a stunning 30% performance gain from porting it to x86-64 with no optimization. A significant portion of this gain probably comes from the benefits associated with x86-64's increased number of registers. The rest is from the Opteron's on-die DDR controller, large L2 cache and microarchitectural enhancements.

Reacties (33)

Ik wacht echt vol smacht op de eerste cerkrijgbaar processoren op dit platform...Als het alles is wat het belooft te zijn wil ik er wel graag een halen. In de tussentijd nog even sparen.

Imho heeft het x86-64 platform een hoop voordelen op het ia-64 platform maar de tijd zal ons leren wat "de markt"ervan vindt.
Ik wacht vol smacht tot ze lekker goedkoop zijn geworden, dan vervang ik mijn XP2700+ :+
hoeveel performance winst kan je halen met 3d apps (ala max)
Ik denk niet dat dat zoveel is. Dat zijn 32-bits applicaties en de cpu draait dus ook in die modus. Misschien dat een volgende versie van die programma's 64-bits worden.
De CPU draait alleen in 32-bits modus als je een 32-bits besturingssysteem draait. Hij draait in 64-bits modus als je bijv. XP64 of een 64-bits Linux-variantje runt, maar je 32-bits applicatie gebruikt dan gewoon de mogelijkheden van besturingssysteem+processor niet optimaal.
Ik dacht dat een Athlon 64 ook snelheidswinst zou hebben in 32bit-apps. Het zou natuurlijk wel een kleine winst zijn, maar toch.
hoeveel performance winst kan je halen met 3d apps (ala max)
De winst zal denk ik niet echt uit de 64-bits komen, aangezien 3D-applicaties vooral floating-pointberekeningen gebruiken en de floating-pointoperaties waren in 32-bit CPU's ook al 64-bit (intern zelfs 80) en zijn dat in 64-bit CPU's nog steeds. De winst zal dus vooral uit de extra registers gehaald moeten worden...
Ik denk dat je toch nog wel een aardig tijdje moet wachten voordat je zo'n ding in 64 Bit mode gebruiken kan.

Stel, je hebt Win64, daar kan je dan nog geen 32 bit apps op installeren ? En dus zal je nog altijd lekker in 'Legacy' mode draaien :7

(Of zie ik het nou helemaal verkeerd ? :? :+)
De tweede modus is long mode, de processor wordt nu aangestuurd door een 64-bit besturingssysteem. Dit besturingssysteem is in staat om zowel 64 als 32-bit applicaties uit te voeren.
Je bent dus wel instaat om 32-bit apps te draaien in 64-bit (long)mode
niet onder *nix :)
Als er onder *nix geen 32 bit ondersteuning is in een 64-bit besturingssysteem, waarom heeft AMD dan een demo laten zien met zowel 64-bit als 32-bit applicaties onder de distro van SuSE gecompileerd voor x86-64?
Waarom gaan ze eigenlijk niet meteen over naar 128 of 256 bit? Grafische processoren doen dit ook al. Is dat zo moeilijk ofzo? :?
Als het zou kunnen zouden ze het wel doen...maar er zal wel een beperking opzitten
no shit sherlock. de vraag is nujuist, wat dat obstakel precies is. ik vroeg mij dit ook al namelijk af dus als iemand met kennis van zaken kan vertellen waarom ze inderdaad niet meteen overstappen op 128/256bit (consoles werken al lang met meer dan 64bit en transmeta maakt ook 256bit cpu's).

[edit] danku heren onder mij voor deze uitleg.
Consoles werken NIET met meer dan 64-bits, dit is pure marketing.

Er wordt nogal wat gesmeten met 'bits' hier maar voordat je het hierover gaat hebben stel ik voor dat je eerst het artikel leest waar deze newspost over gaat.

Het komt er op neer dat je pas over een 64-bits processor spreekt als de interne datapaden en registers uit 64-bits bestaan. Dit biedt als voordeel dat je (zoals hierboven ook al staat) meer dan 2^32 bits is 4Gbyte geheugen kan adresseren, en dat je operaties met 64-bit datatypen sneller kan uitvoeren. (vrijwel alleen nodig voor wetenschappelijke doeleinden)

64-bits heeft niets te maken met de instructies. Zo zie je dat bij de PowerPC ISA instructies gewoon uit 32-bits bestaan. Je programma's worden dus vooral groter doordat de datatypen groter worden. Een integer die eerst 32-bit was wordt nu opeens 64-bit, evenals pointers etc.

Waarom noemen ze consoles dan 128-bits? Omdat er SIMD (Single Instruction Multiple Data) extensies opzitten (ala MMX en SSE) waarvan de instructies wel bestaan uit 128 bits. Let op: alleen de SIMD instructies bestaan uit 128 bits, alle andere instructies zijn in het geval van de GameCube gewoon 32-bits. (PowerPC Gecko CPU).

Transmeta's 256-bit processor is niks anders dan een VLIW processor die werkt met instructie blokken met een grote van 256-bits.

Het vergelijken van CPU's en GPU's is zowieso al niet te doen eigenlijk, vanwege de totaal verschillende doeleinden van deze chips.
Maar GPU's zijn helemaal niet 256-bits zoals nVidia maar al te graag zou beweren (denk aan de orginele geForce256). Ze benaderen het geheugen alleen in 128 bits DDR (=256 bits per clock), dat maakt de GPU's helemaal niet meteen 256-bits ofzo (en de R300 dus ook niet 512-bit). Op dit moment kan je de nieuwste GPU's hoogstens 128-bit noemen omdat ze nu eindelijk eens 128-bits floats ondersteunen.
(vrijwel alleen nodig voor wetenschappelijke doeleinden)
das natuurlijk een beetje onzin.. de meeste games zitten vol met double precision floats dus ook games zullen hiervan profiteren.
[reactie op abraxas]
de meeste games zitten vol met double precision floats dus ook games zullen hiervan profiteren.
Het artikel zegt dus:
Alleen integers worden 64-bit, floating-pointgetallen waren al 64-bit en vectorgetallen blijven 128-bit.
Voor floats maakt het dus niets uit. Misschien eerst het artikel lezen voordat je andermans opmerkingen als "onzin" afdoet?
Het is niet zo dat groter meteen beter is, er komen daarbij heel veel optimalisaties in de subsystemen van een OS kijken. Stel je hebt een programma dat bestaat uit 1024 instructies. Als je al die instructies in 8 bits kan coderen dat beslaat je programma slechts 1KB, bij 256 bits instructies wordt je programma 32KB, je hebt dus bij grotere instructies veel meer geheugen en cache nodig. De databussen worden ook groter, en dat zou betekenen dat bij gelijke bussnelheden je veel meer data moet vervoeren. Wel zou je meerder instructies in één instructie word kunnen proppen zoals bij een VLIW architectuur, maar gelet op de performance van bijvoorbeeld IA-64 is nog moeilijk gebleken om instructie parallelisme goed uit te buiten.
Dit zal later wel in de vorm van een soort MMX erbij komen. (MMX bood de mogelijkheid om op 2x een 32bits waarde, of 4* een 16 bit of 8* een 8 bits waarde een zelfde operatie uit te voeren. Oftewel voor een pixel bestaande uit 24 kleurwaarden moesten vroeger 3 operaties gedaan worden, terwijl dat met MMX 2 pixels tegelijk kon.)
Probleem met het maken van een te grote stap ineens, is dat je dan te veel dingen tegelijk aan moet gaan passen en dat leidt tot veel hogere kosten en een toename van fouten.
Ik denk dat grafische processoren met name met 128 en 256 bit registers werken en verder niet. Oftewel de FPU is gewoon wat breder gemaakt.
Om een hele CPU-architectuur om te gooien kost aanzienlijk meer moeite.
Klinkt allemaal weer heel positief.

Ik denk ook dat een 128bits overkill is: Dan heb je een legacy-mode nodig voor je 32-bits die bestaat uit 4x1/4 van je CPU, wat 4x zo complex is als een 2x1/2 modus.

En het levert zulke brede datapaden op, dat het ondoenlijk wordt je CPU te produceren op een 0,09nm, dunkt mij. Laat eerst alle software maar doorgroeien naar 64-bits, zodat we over 4 of 5 jaar kunnen gaan porten naar een 128-bits CPU op 0,035nm, ofzo.

ps. nog een vraagje:
Als er 2x zoveel registers beschikbaar zijn (joepie! de 8086 wordt weggeflikkerd! mijlpaal!), krijgen we dan ook 2x zoveel IRQ's?
Dat zou een opluchting zijn voor ACPI, lijkt mij!
Geen gedeelde registers meer, geen gezeik met IRQ's, voorlopig? Volgens mij was ook bij de overstap van 16bit naar 32bit het aantal registers verdubbeld, evenals het aantal IRQ's, toch? (van 8 naar 16)
Ik denk ook dat een 128bits overkill is
Zo was er ook een of andere software-bakker uit Redmond die dacht dat meer dan 640 Kb nooit nodig zou zijn... :)
Dat werd gezegd toen 640 kb RAM al realiteit was. Het was trouwens IBM die de grens gesteld heeft.

En van 32-bit naar 64-bit zit een factor 2^32 verschil. Van 2^20 b tot 2^30 b RAM heeft 20 jaar gekost. Als de ontwikkeling in hetzelfde tempo doorgaat zou het dus minimaal 70 jaar kosten.

BTW, IRQs en registers hebben niks met elkaar te maken.
over 4 of 5 jaar ? :) ik hoop 't niet :) ik zelf denk meer aan een jaar of 10..
Ik denk toch dat AMD hiermee slimmer is dan Intel. Als je een processor levert die perfect als 32-bits werkt, kun je snel grote aantallen produceren tegen lage kosten en deze verkopen aan consumenten die slechts 32-bits gebruiken. Zo heeft iedereen binnen een paar jaar een 64-bits pc op zijn bureau staan, en dat maakt de drempel voor Microsoft een stuk lager om tijd en geld te steken in een 64-bits consumenten-OS. En voor Linux is dit al helemaal leuk, want een 64-bits distro zal helemaal Windows XP's kont gaan schoppen natuurlijk, vooral als het op 'de zelfde' hardware draait, en dat effect is voor Microsoft een stok achter de deur om snel met de x86-64 port van XP te komen.

Het Intel-idee is veel moeilijker. Niet compatibel met voorgangers, erg duur in aanschaf, gericht op de kleine server-markt, enzovoorts. Als Intel een monopolie zou hebben dan zouden ze hiermee succes hebben, maar dat is nu absoluut niet meer het geval.

Waar concurrentie is, is terugwaartse compatibiliteit veel belangrijker dan absolute performance.
kun je snel grote aantallen produceren tegen lage kosten en deze verkopen aan consumenten
Dat snel produceren kon nog wel eens een probleem worden, er zijn nu namelijk ook al steeds veelste weinig snelle Athlon-processors (de 3000+ is al lang geintroduceerd, maar erg moeilijk te krijgen, net als alle vorige snelle Athlons). En als in het begin de vraag veel groter is dan het aanbod, zal iedereen daar goed van balen en dat is verre van ideaal voor AMD... (en daarbij komt nog dat de CPU's dan veel duuder worden :( , ook niet goed voor een nieuw product als de Athlon 64/Opteron) ).
AMD said: ""64 Bit or else"

Intel said: "Else"

voor serieus commentaar op de 64 bits ontwikkelingen kijk eens op

http://www.overclockers.com/tips00303/
of
http://www.overclockers.com/tips00304/
Voor serieus commentaar zou ik daar absoluut niet gaan kijken. Terwijl de schrijver anderen kwalijk neemt dat ze hun eigen mening als algemeeen idee presenteren, doet hij hetzelfde.

Hij probeert krampachtig te verdedigen waarom Intel 64-bits CPU's in eerste instantie niet voor de algemene gebuiker beschikbaar wil maken. Zonder op technische details in te gaan geeft hij aan dat de markt veel te klein zal zijn, en dat het dus onzin is om die kleine markt te bedienen.

Hij noemt zelf een getal van 5% van de processoren (als maximum, en de manier waarop hij aan de 5% komt is ronduit belachelijk). Aangezien 5% van de CPU's is een behoorlijk aandeel is, zou ik verwachten dat AMD en Intel daar toch behoorlijk hard om zullen vechten.

Waar hij totaal niet naar kijkt is dat dit de logische stap is in de evolutie van de PC. de huidige techniek van de processoren begint in de buurt van zijn limieten te komen. Door de rekenkracht uit te breiden door van 32 naar 64 bits verwerking uit te breiden, is er nog wat meer tijd om te zoeken naar een nieuwe techniek (ik geloof dat IBM bezig is met het zoeken naar licht-gebaseerde procs.)
Om daar plek voor vrij te maken zijn segmented memory en ondersteuning voor real mode en virtual-8086 mode in long mode geschrapt.
Wat houdt dit specifiek in? Wat is er niet meer mogelijk dan, als je dit schrapt?
Je kan met X86-64 in 64-bit mode alleen in protected mode werken. Nu schakelt vrijwel elke systeem redelijk snel na het booten over op protected mode en is real mode dus niet zo belangrijk. Systemen die niet op protected mode overschakelen zijn meestal oude code 8086 die dus ook geen 64 bit zullen gebruiken. (bijv. als je DOS opstart)

Bij 386 en hogere processoren kan je bij een Call of Int aangeven of de code op de bestemming in 16 of 32 bit en of virtual8086 moet worden uitgevoerd. Ik vermoed dat dit uitgebreid zal worden meteen 64 bit optie en dat deze geen virtual86 ondersteund. De virtual86 mode is ook bedoeld om oude code te kunnen draaien. Het ergste wat dit betekend is dat je geen 64bit DOS programma kan draaien.

IMHO is dat niet zo'n probleem. Ik ken namelijk geen 64bit DOS applicaties.
Zou dit betekenen, dat booten met een DOS-bootdisk niet meer mogelijk is?
Nee,

Bij het booten staat de processor in real mode en kan dus gewoon DOS laden. Overschakelen naar protected mode, (of long mode voor 64 bit) wordt over gelaten aan het OS.

Wat niet mogelijk is, is om DOS software native in long mode te draaien.

[typo]
Als ik het goed heb begrepen, was dit alleen voor 64-bits-modus en die modussen werden voor 32-bit's applicaties al niet meer gebruikt, alleen door 16-bit apps (vooral DOS).
De geschiedenis herhaalt zich. Bij het invoeren van de 80286 weden ook 2 modi ingevoerd: protected en real mode. De real mode was er om de oude DOS zut te kunnen draaien (legacy dus) en de protected mode voor nieuwe applicaties. Alleen heeft DOS (en zijn nazaten in 3.x en Win 9x) zolang overleeft dat pas nu (bij de grootschalige invoer van WinXP) de real mode definitief maar de prullemand kan. Het zal dus nog wel even duren voordat 64 bit echt gemeengoed wordt.

Op dit item kan niet meer gereageerd worden.



Populair: Tablets Nokia Websites en communities Lumia Smartphones Laptops Sony Apple Games Politiek en recht

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013