Naast sneller 64-bits getallen kunnen verwerken en direct een groter geheugen kunnen aanspreken (waar een driver niet meteen heel veel voordeel van heeft), zijn er zeker ook nadelen van 64-bit computing.
Zo zijn alle adressen en adresberekeningen (toch een redelijk deel van computer programma's, zeker 'onder de motorkap') hoppa in één klap 2 keer zo groot geworden. Ook als je niet echt 64-bits nodig hebt. Dit betekent echter wel dat de programma's meer geheugen innemen, grotere executables hebben en, niet onbelangrijk, meer van je geheugenbandbreedte vragen. Er moeten immers 64-bits over de bus i.p.v. voorheen 32-bits.
Het is dus allerminst vanzelfsprekend dat 64-bits programma's sneller lopen dan 32-bits programma's...
EDIT: de bus naar je RAM is niks breder hoor...
Natuurlijk kan je 32-bits code executeren op 64-bits systemen. Maar gaat dat sneller dan? De FP lijkt te denken dat 64-bits altijd sneller moet kunnen zijn dan 32-bits...
Het gaat er mij een beetje om om die 64-bits mythe te ontkrachten. Die is namelijk nog erger dan de megahertz mythe. Men lijkt vaak te denken dat 64-bits computing bijna 'vanzelf'' veel sneller moet zijn dan 32-bits computing, het getalletje is immers wel 2x zo groot!
EDIT2: of de (geheugen) bussen nu 2x zo breed zijn, 128 bits breed of 10 triljoen bits breed: een 64-bits waarde/adres zal er 2x zoveel van opslokken dan een 32-bits getal/waarde. Maakt dat veel uit? Ik weet het niet. Maar er wordt hier al driftig gekeken naar verschillen in moederbordsnelheden van 1%, dus dit lijkt me zeker relevant.
De bussen zijn dan ook 2x zo breed, dus eigenlijk maakt het geen hol uit. Alleen dat ze meer ruimte inneemt. Daarnaast is er nog zoiets als WoW. Dat executeert 32-bits code in een 64-bits shell.
Er is idd geen noodzaak om textbestanden met 64 bits op te slaan, en dat hoeft du ook niet.
Maar met WoW hoef je ook weer niet echt blij te zijn aangezien het trager wordt door thunking. (omzetten van 32 naar 64 bits adressen)
Klopt niet.
Een Opteron bij voorbeeld, gebruikt 48bit adressering voor het geheugen. En dan nog, als je een jump maakt, gaat het om het aantal bytes en dat veranderd niet, ongeacht de adressering.
Klopt wel. Waar het om gaat is dat je een 64 bits register eerst zal moeten vullen om een jump uit te kunnen voeren. Als dat 64 bits address in het geheugen staat, dan zal je dus eerst 64 bits die ergens in het geheugen staan over je datalijntje binnen moeten halen voordat je de opdracht kan geven om een jump te doen. (om even bij jouw voorbeeldtje te blijven)
Overigens is het inderdaad zo dat je feitelijke jump er niet door beinvloed zal worden.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.gif){kind=icon}
Microsoft is begonnen met het aanbieden van webcasts over de 64bits-edities van Windows. Onder de titel 'Resources for the Next Wave: 64-bit Processing Power' werd op 1 november een reeks webcasts aangekondigd waarin onder andere uitgelegd wordt hoe 32bit-code zonder aanpassingen op 64bit-systemen gedraaid kan worden, maar ook hoe men native 64bit-software kan schrijven. Verder wordt er aandacht besteed aan de 'next generation' ontwikkelingstools en komt ook de procesarchitectuur van 64bit-software aan bod. Volgens de webcasts is 64bit-ondersteuning vandaag beschikbaar in de volgende edities van Windows Server 2003, Windows XP, SQL Server 2005 en Visual Studio 2005.
10:40
09:14
Door 
.
![[show]](http://tweakimg.net/g/if/comments/button_down.gif "Reactie uitklappen")
. Net zoiets als de CD's met service packs en zo die je nu altijd al kunt bestellen lijkt me dan.
