'Windows 8 krijgt 128bit-kernel'

He ja, laten we lekker duur gaan doen...

Een foundation betekend een keurings process een veel langzamer ontwikkeling van nieuwe technieken en veel minder flexibiliteit om af te wijken van het basis ontwerp en extra instructies toe te voegen. Omdat er op eens commisies over moeten beslissen tientallen verschillende bedrijven zegenschap willen hebben en meer van dat soort problemen.

Ik denk eigenlijk dat Intel een nieuwe poging moet doen om met een nieuwe architectuur op de proppen te komen. Het klinkt gek maar x86 is vere van efficient en na al die jaren met alle kennis die is op gedaan moet het mogenlijk zijn een veel betere architectuur te ontwerpen dan de x86 die in middels ook al weer heel wat jaartjes mee gaat.
Intel had het idee dat de Itanium CPU deze nieuwe architectuur was maar door verschillende problemen zo wel binnen de samenwerking met HP als in de eigen organisatie is die belofte nooit waarheid geworden. En nog steeds sukkelt Intel met het Itanium platform.

Ik denk dat de hoge heren bij Intel zelf heus wel weten dat als zij het niet doen iemand anders van zelf met een beter ontwerp zal komen. Intel zal heus niet in een keer uit de markt gedrukt worden maar het lijkt me dat ze het risico niet willen lopen dat iemand anders dan zij zelf de computer architectuur van de toekomst zal bepalen.
Ik denk dan ook dat Intel ergens op de achtergrond een team aan het werk heeft dat aan het werk is om een processor architectuur te ontwerpen die misschien de belofte die Itanium eens was waar kan maken. Misschien zelfs wel compatible met de x86 architectuur al was het maar om op die manier gemakkelijk de huiskamers binnen te kunnen rollen.

x86 is nog lang niet dood maar het lijkt me sterk dat het tot het einde der dagen de architectuur zal zijn waar alle PC's op draaien.

Als je het uitstelt zit je wanneer het wel "nodig" is toch alsnog met ditzelfde probleem? Verder groeit het aantal GB ram ook niet lineair natuurlijk, dus dit argument gaat ook niet op.

Je moet het in perspectief zien, tussen de adresruimte die je met 64-bit krijgt (16777216 TB) en de hoeveelheid geheugen die momenteel courant is (4GB) zit een factor 4 miljoen. In 10 jaar tijd is de 'instap' hoeveelheid geheugen dus zo'n 1000x groter geworden (4MB naar 4GB), dus dan kan het geheugengebruik de komende 10 jaar 4000x sneller groeien en dan nog kunnen we 10 jaar vooruit. Of het groeit 'maar' 400x sneller dan de afgelopen 10 jaar en dan kunnen we 100 jaar vooruit.

Wat zijn je bronnen waar je 2x zo grote code en geheugen gebruik vandaan haalt?

Goed lezen: ik zei tot 2x zoveel geheugen, en de redenatie is simpel: in het worst-case geval slaat een programma al zijn data in het geheugen op als 32-bit woorden (dwords), of het nu booleans zijn (dus 1 of 0) of 32-bit getallen. Ga je naar een 64-bits adressering dan slaat hetzelfde programma in het worst-case geval alles op als 64-bit getal, en dan heb je dus 2x zoveel geheugen gebruikt. In de praktijk wordt data in het geheugen ook als bitfields, bytes, words en dwords gebruikt dus zal het in de praktijk niet op 2x zoveel geheugen gaan. Echter zijn moderne CPU's helemaal geoptimaliseerd voor geheugentoegang op 4-byte of 8-byte boundaries, dus veel compilers genereren graag code die structuren in het geheugen zo aligned dat elk stuk data 4 bytes beslaat, of dat nu nodig is of niet. Die alignment is bij een 64-bit CPU 8-byte, waardoor dus tot 2x zoveel RAM kan worden 'verspild'.

Wat betreft code size: de aanduiding '64-bit' op een CPU is nogal een fuzzy aanduiding, maar in de volksmond betekent het 'CPU met 64-bit registers, 64-bit instructiewoord en 64-bit adresruimte', doorgaans zijn de bitbreedtes van registers, instructiewoorden en adresruimte aan elkaar gelijk (maar dat hoeft niet), omdat je die 64 bit adressen of registerwaarden natuurlijk ook graag in 1 instructie codeert => 64-bit instructies. En native 64 bit programma gebruikt dus 64 bits voor elke instructie, terwijl een 32-bit programma er 32 gebruikt => code size verdubbeld.