Hans de Vries over toekomstige 64-bit x86-chips van Intel

Op Chip Architect is weer een uitgebreid artikel verschenen met daarin een verdere analyse van de Intel Prescott-core. Na een viertal eerdere delen waarin al veel aanwijzingen werden gevonden levert Hans de Vries nu het definitieve bewijs dat ook Intel zijn x86-processor geschikt heeft gemaakt voor 64-bit instructies. Dat is een interessant gegeven, want nu AMD de Opteron heeft uitgebracht zitten veel mensen te wachten op een antwoord van Intel op x86-64. Op dit moment kan het dan nog wel waar zijn dat een gemiddelde consument geen 64-bit processor nodig heeft, maar over enkele jaren zal die situatie heel anders zijn. De beperkingen van 32-bits adressering worden in alle moderne operating systemen namelijk al ruim vóór de limiet van 4GB fysiek geheugen merkbaar. Intel zou er natuurlijk voor kunnen kiezen om IA-64 vanuit het high-end serversegment naar beneden te schalen, maar het begint er steeds meer op te lijken dat de gigant het voorbeeld van AMD gaat volgen door x86 uit te breiden met 64-bit features.

De 0,09 micron Prescott-core blijkt net als Hammer te kunnen werken met 64-bit getallen en 48-bits adressen om virtueel geheugen mee aan te spreken. Dit blijkt uit onder andere uit het bestuderen van de TLB, het trace cache en de target buffers. De precieze metingen en berekeningen zijn te vinden in het artikel, maar het komt er bij alledrie op neer dat ze ten opzichte van de Northwood-core naar verhouding groter zijn geworden en/of een andere vorm hebben gekregen. Veranderingen die - verrassing - precies kloppen met toenames van 32 naar 48 of 64 bits. Ook is nu duidelijk geworden dat de tweede integer-core die hier wordt besproken onmogelijk gebruikt kan worden om HyperThreading te verbeteren, maar juist wel uitermate geschikt is om het 64-bits rekenwerk te doen.

De nadruk van bovenstaande alinea ligt op het woord kan. Hoewel het zonder twijfel technisch mogelijk is voor Intel om net als AMD voor het einde van het jaar een x86-64 chip voor desktops op de markt te hebben, is het is niet erg waarschijnlijk dat dat ook gaat gebeuren. Er zijn echter wel verschillende aanwijzingen dat bij Potomac, de 0,09 micron Xeon MP, de 64-bit technologie ingeschakeld zal zijn. De desktopchip en Xeon DP zullen in eerste instantie gewoon 32-bits blijven. In het artikel wordt gespeculeerd dat Prescott Pentium 5 gaat heten en de ongeveer een jaar later op de markt te verschijnen 64-bit versies van de core Pentium 6 gaan heten.

Dit lijkt ons niet erg waarschijnlijk, maar het mag inmiddels wel duidelijk zijn dat heel wat specs van de volgende core met gemak verdubbeld kunnen worden. De grote vraag blijft alleen wanneer Intel dit gaat doen, en hoe ze een 64-bit Pentium / Xeon in hun strategie en marketing gaan passen. Eventuele compatibliteit met de (vrij te gebruiken) x86-64-standaard van AMD zou waarschijnlijk flink slikken zijn voor Intel, maar wellicht is dat uiteindelijk toch de beste koers om te volgen. De tijd zal het leren, maar het plaatje zou er ongeveer als volgt uit kunnen zien:

			Pentium 4 (Nu) Northwood (SP) Prestonia(DP) Gallatin (MP)		Pentium 5 (H2 2003) Prescott (SP) Nocona (DP)		Pentium 6 (H2 2004) Tejas (SP) Jayhawk (DP) Potomac (MP)
	Data		32-bit		32-bit		64-bit
	Virtueel geheugen Fysiek geheugen		32-bit 36-bit		32-bit 40-bit		48-bit 40-bit
	Registers in architectuur		8		8		16?
	HyperThreading		Northwood: 2-way Prestonia: 2-way		Prescott: 2-way Nocona: 4-way?		Jayhawk: 4-way Potomac: 4-way
	Frequentie		2,0GHz ~ 3,2GHz		3,4GHz+		4,0GHz+
	SPECint2000 score		1250		1500		1900
	L1 data cache		8KB		16KB		32KB
	Trace cache		12K µOps 80KB 3 µOps per cycle		16K µOps 128KB 4 µOps per cycle		16K µOps 128KB 4 µOps per cycle
	L2 cache		512KB		1MB		1MB
	Integer registers		128 x 32-bit		256 x 64-bit		256 x 64-bit
	Floating point registers		128 x 128-bit		256 x 128-bit		256 x 128-bit
	Load buffer		48 items		96 items		96 items
	Store buffer		24 items		48 items		48 items

Voor de liefhebber staat er een uitgebreidere tabel in het originele artikel, samen met nog wat meer informatie over het scheiden van de x87 floating point unit en de SSE-core, en een foto van hoe de mysterieuze LaGrande-beveiligingsmodule er op de core uit ziet. Daarnaast vind je er trouwens ook nog mooie 1600x1200 wallpapers van de Pentium 4 (Northwood) en de "Pentium 5/6" (Prescott) cores. De moeite waard om even langs te gaan dus.

Reacties (66)

[EfBe]

De beperkingen van 32-bits adressering worden in alle moderne operating systemen namelijk al ruim vòòr de limiet van 4GB fysiek geheugen merkbaar.

Dan mag jij uitleggen waarom dit zo is. Ieder modern OS geeft ieder proces een 4GB adresseringsgebied. Voor servers met databases van 4GB of groter, ala, maar voor desktops zie ik echt niet in waarom je uberhaupt 2GB memory zou moeten hebben, laat staan 4GB. Zelfs bij zeer intensieve renderoperaties tijdens videobewerkingen bijvoorbeeld, waarbij meerdere videostrreams worden geblend, heb je aan 4GB echt meer dan genoeg, en dan praten we dus ook over een niet alledaagse situatie, want wie edit er op hoog niveau video met meerdere streams thuis ?

Doordat de memory managers van alle moderne OS-en net doen alsof er 4GB memory in het systeem zit, heeft software er sowieso geen problemen mee. Ik zie niet in waarom operating systems VER VOOR de 4GB de beperkingen (van dus maar 4GB) merkbaar voelen. Dus, Wouter, leg eens uit

[DiGuru]

Die 4GB is het absolute maximum, en wordt door het OS in stukjes verdeeld. Windows reserveert bijvoorbeeld standaard 2GB voor eigen gebruik. En dat een applicatie de beschikking heeft over een adresbereik van minimaal 2GB (Meestal meerdere segmenten van 4GB per stuk), wil niet zeggen dat dat geheugen ook in het feitelijke geheugen gemapped kan worden.

Verder is bijvoorbeeld een database van meer dan 2GB (het eigenlijke maximum) al lang gemeengoed geworden, je moet dus al truukjes gaan uithalen om daarmee te kunnen werken.

[EfBe]

Windows reserveert 2GB voor eigen gebruik. Toch hebben alle 32bit processen 4GB aan adresspace. (m.a.w: windows swapt kernel space uit, de kernelspace is nl. ook virtual gemapped en is veelal niet groter dan 50MB)

Maar dat even daargelaten: we praten hier over de desktop. En dan daarin een 64Bit processor en dat dat NODIG is, want de 32bit limit schijnt je tegen te werken.

2GB memory is meer dan 3CD's! Welk desktop programma voor de gemiddelde gebruiker heeft meer dan 3CD's aan data tegelijk nodig (zodat het in memory moet worden gehouden)? Ik ken er geen een. De enige database die ik ken die 3CD's beslaat voor een eindgebruiker is de MSDN library, en die heeft een goede index, ik hoef nl. die gehele library niet in memory, die index is veel sneller met zoeken dan de complete 2GB doorploegen.

Jij komt aan met databases die 2GB of meer zijn, maar dat zijn vrij grote databases op servers, niet op desktops. Welke database is 2GB groot voor op de desktop? De complete telefoongids van nederland + de gouden gids van Nederland is < 1GB.

Een developer die die databases in memory gaat laden en dan gaat zoeken snapt er niets van. Je kunt beter een index gebruiken van een paar MB waar je de bulk data meer doorzoekt en eventueel die segmenten laden waar je niet met de index doorheen kunt (je moet het toch laden, of je alles in memory laadt of alleen een stukje dat je wilt doorzoeken). Omdat laden vele malen trager is dan memory access, kun je beter dat tot een minimum beperken. Ik laad echt liever 100MB in wat ik dan doorzoek dan 2GB wat ook 100MB doorzoekt. Verder heb ik dan geen 2GB memory nodig.

[iKiddo]

Welk desktop programma voor de gemiddelde gebruiker heeft meer dan 3CD's aan data tegelijk nodig (zodat het in memory moet worden gehouden)?

Je kan toch ook meerdere programma's hebben draaien? De meeste mensen zullen het dan nog niet eens bijna vol krijgen. Maar je kan dan in ieder geval een stuk dichter in de buurt komen als desktop gebruiker.

[Anoniem: 19220]

Ik heb ergens gelezen dat het bij een 32-bits systeem inderdaad mogelijk is om meer dan 4 GB aan RAM te benaderen, maar dat dit op dezelfde manier gebeurt als vroeger (16-bits systemen) bij Expanded Memory gedaan werd, namelijk door steeds een stuk geheugen te verplaatsen naar het beheerbare gedeelte binnen de 4 GB grens (vroeger dus de 1 MB grens (goh, ik word oud)). Op deze manier kun je dus wel een hele berg geheugen gebruiken, maar echt efficient is het niet.
Vraag me niet naar de bron, want die weet ik niet meer.

[Anoniem: 31421]

Wat misleidend in de nieuwspost id,
Bovendien volgende opmerking:
Sinds de PII processor kan de processor 64GB aan geheugen adresseren. De beperking ligt telkens door de chipset-fabrikanten.

[Wouter Tinus]

Sinds de PII processor kan de processor 64GB aan geheugen adresseren. De beperking ligt telkens door de chipset-fabrikanten.

De manier waarop dat gaat is a) (relatief) ontzettend traag en b) lastig te implementeren (kan je niet automatisch door het operating systeem laten doen heb ik wel eens gelezen, kan inmiddels opgelost zijn).

Dan mag jij uitleggen waarom dit zo is. Ieder modern OS geeft ieder proces een 4GB adresseringsgebied. Voor servers met databases van 4GB of groter, ala, maar voor desktops zie ik echt niet in waarom je uberhaupt 2GB memory zou moeten hebben, laat staan 4GB. Zelfs bij zeer intensieve renderoperaties tijdens videobewerkingen bijvoorbeeld, waarbij meerdere videostrreams worden geblend, heb je aan 4GB echt meer dan genoeg, en dan praten we dus ook over een niet alledaagse situatie, want wie edit er op hoog niveau video met meerdere streams thuis ?

Dat mag jij in de bron gaan lezen . Het komt er op neer dat je veel meer virtueel dan fysiek geheugen nodig hebt. Je kan dus wel 4GB fysiek aanspreken, (1 of 2GB wordt dan geloof ik sowieso al door Windows afgepakt) maar dan heb je al meer dan 4GB virtueel geheugen nodig om optimaal te kunnen werken.

[EfBe]

Virtual memory heb je idd meer nodig, want je hebt bij veel processes die veel memory eten (bv 1GB elk) wel de virtual mem nodig om dat op te slaan, maar dat is nu ook al zo: bij 256MB memory heb je ook virtual memory nodig om een aantal processen te draaien die bv elk 256MB memory gebruiken. M.a.w: bij beschikbare fysieke hoeveelheid memory X heb je altijd een X*Y hoeveelheid virtual memory nodig, want er is altijd te weinig, ook bij 64bit.

(verder is virtual memory cheap, en niemand heeft mij nog kunnen overtuigen dat een DESKTOP bak uberhaupt meer dan 1GB memory nodig heeft. Ik develop de gehele dag software en 512 is dan zat, wat moet je met meer? )

[35MHz OC]

Otis, toekomst laat zich niet tegenhouden, omdat wij 'old timers" het nu wel genoeg vinden....

Er zal een dag komen dat een gemiddelde instap-pc met meer dan 8 GB over de toonbank gaat en dat is dan niet omdat het spiffy klinkt, maar omdat (nieuwe) interface software zoals biometrie en voice recognition deze hoeveelheden nodig hebben.

De dan "dominante" generatie zal op onze bakken neerkijken als steentijd gedrochten...

Het is gevaarlijk om te zeggen dat iets nu echt wel genoeg is....

[nhimf]

Ik kan me nog wel herinneren dat wij een 486 met 4mb geheugen kregen.
Dat was extreem veel 4mb ja!!!!

Zo zal het altijd gaan, de pc blijft sneller worden, meer geheugen , meer hd (tot dit systeem eruit gaat) enz.

ps. Waarom je al ver voor de 4gig al last krijgt van het limiet is het volgende (staat geloof ik ook achter de link)
Je stopt wat in het geheugen. Vervolgens stop je meer in het geheugen. Dan sluit je wat en hou je een "gat" over. Dit kan niet altijd gevult worden door een ander prog, omdat het groter is. Hierdoor krijg je gaten in je geheugen.
Dit principe heet fragmentatie. Iedereen kent het wel bij de hardeschijf. Het probleem is alleen, dat je niet zomaar even je geheugen gaat defragmeteren.
Hierdoor zal je met een pc met een limiet met 4gb nooit 4gb vol krijgen en toch de melding krijgen dat je onvoldoende geheugen hebt.

[Bl@ckbird]

Voor servers met databases van 4GB of groter, ala, maar voor desktops zie ik echt niet in waarom je uberhaupt 2GB memory zou moeten hebben, laat staan 4GB.

640k Should be enough for anybody.

Bill Gates - 1981

[Anoniem: 25942]

hmmm, todat je gaat overwegen wat je allemaal kunt doen met een mooie grote ramdrive....of een OS wat op een veel efficientere manier gebruik kan maken van het geheugen...temeer daar processoren in hoog tempo sneller worden begint de harddisk meer en meer de bottleneck van een systeem te worden. Stel je hierbij voor het gebruik van RAM voor je internet cache, om tijdelijke bestanden in te plaatsen, etc. etc.

[iKiddo]

[Reactie op Otis]
Turrlijk kan je op je geheugen wel statische data plaatsen. Ook als het daar niet voor bedoeld is/was. Als je, zoals hij zei, een mooie ramdisk maakt en daar dingen op zet die je vaak gebruikt (grote programma's zoals OO.org) kan dit een stuk sneller worden dan dat je alles de hele tijd van je harde schijf moet lezen.

[EfBe]

En dan denk jij 2GB vol te krijgen? Ga eens 2GB downloaden via fast adsl. Dat kost je uuuren. 2GB is erg veel hoor. Dat is mijn punt: het is dermate veel, dat je het gewoon niet vol krijgt. Wel met statische data, maar daar is je memory niet voor. Je memory is voor het opslaan van data en programmacode dat op dat moment nodig is. Je moet het nl. allemaal inladen.

[arjankoole]

Voor servers met databases van 4GB of groter, ala, maar voor desktops zie ik echt niet in waarom je uberhaupt 2GB memory zou moeten hebben, laat staan 4GB.

grafische workstations, 3D modeling en animation workstations, etc, etc.

okay, voor de huis tuin en keuken gebruiker is het niet echt intressant, nog niet althans, maar over een aantal jaren, 2024 dacht ik, raken de 32bits seconden op, en moeten we er echt allemaal aan gaan geloven. Nu al 64 bit in de mainstream markt introduceren, zoals AMD duidelijk van plan is, tja, da's alleen maar slim natuurlijk, voorkomt de stress zoals die rond de y2k bug was, alleen zal dit probleem een stuk ernstiger zijn dan de hete lucht waarop het millenium 'probleem' voort raasde.

[EfBe]

raken de 32bit seconde op? Wat heb jij gerookt

Unix heeft een probleem, dat telt het aantal seconden sinds 1970, en dat raakt idd ergens op. Als je echter een ander datum formaat neemt, of een andere referentiedatum, dan raken ze niet op. Je kunt ook de datum anders opslaan, zodat je nooit in de problemen komt. (wat al zo wordt gedaan btw, omdat je in het 32bits model van alleen seconden tellen geen milliseconden kunt opslaan bv. De pc high performance counter gaat elke 49 dagen over de kop, dus zo erg is het echt niet wat jij beweert).

64bits is totaal onnodig op de desktop. meer dan 1GB ram ook. Je kunt wel gaan beweren dat je dan meer zaken in memory kunt houden, maar dat komt er niet vanzelf, dat moet je dus inladen.

Of je dat nu laadt wanneer je het nodig hebt (lazy loading) of 'up front', dat maakt niet uit, de laadtijd is gelijk. Echter bij lazy loading heb je genoeg aan veel minder memory, je laadt nl. alleen dat in memory wat je kunt gebruiken. Tot op heden is gebleken dat dat zeer goed te doen is, zeker met 512MB memory. Stel je eens voor hoeveel 2GB memory is. Ik krijg zelfs met zware development sessies in vs.net mijn 384MB memory niet vol, laat staan dat ik 2GB vol zou krijgen. De doorsnee desktop gebruiker is alleen maar minder intensief met zijn computer bezig: wat tekstjes tikken, email sturen, wellicht een videofilmpje inladen van de camera en doormailen, wat fotootjes van zn 640x480 camera inlezen en bewerken... dat kan nu al op een 256MB bak.

Ergo: 64bit op de desktop is pure marketing-poop.

[Anoniem: 14842]

Bl@ckbird schreef:

640k Should be enough for anybody.
Bill Gates - 1981

Waarmee hij natuurlijk 640kazillion bytes bedoelde

[Anoniem: 60780]

maar voor desktops zie ik echt niet in waarom je uberhaupt 2GB memory zou moeten hebben, laat staan 4GB. Zelfs bij zeer intensieve renderoperaties tijdens videobewerkingen bijvoorbeeld, waarbij meerdere videostrreams worden geblend, heb je aan 4GB echt meer dan genoeg,

Jij bent zeker ook zo'n persoon die 15 jaar geleden dacht dat 640K voor iedereen genoeg zou zijn?

[Anoniem: 14842]

Ik dacht telkens dat de 64 bits ook voor een snelheidswinst zorgde. Vandaar de betere prestaties van de Athlon64. Maar schijnbaar heeft de laatste dus gewoon een anders geoptimaliseerde core (qua fpu) en heeft de performance an sich niets met 64/32 bits te maken.

Mag ik daaruit dan concluderen dat 64 bits vooral nut heeft omdat je er gewoon meer geheugen mee kunt adresseren. Of heeft het toch (neem aan van wel) ook een grote invloed op de daadwerkelijke berekeningen Ik kan me bijvoorbeeld voorstellen dat zeer grote wiskundige berekeningen van meer dan 32 bits niet in 1 keer door de proc. behandeld kunnen worden en er dus ge-cached moet worden, terwijl de 64 bits dit in 1 berekening zou kunnen doen, of beredeneer ik nu hélemaal verkeerd?

Ik zo geen verklaring vinden waarom Intel de 64 bits opties niet inschakeld als die alleen maar een performance boost kunnen geven. Misschien heeft Intel de chip nog niet zo goed voor elkaar en valt de performance tegen. Of misschien willen ze niet zelf concureren met de Itanium (compleet andere doelgroep, maar ala).

[Wouter Tinus]

Nee, je beredeneert het precies goed eigenlijk. De Hammer is vooral sneller dan de Athlon vanwege de verbeterde frontend en geïntegreerde geheugencontroller. Het "aantal bits" van een processor staat in principe los van de performance, net als de kloksnelheid in theorie niets wil zeggen .

[Ruuddie]

Maar.. wat heeft het dan voor zin om op 64-bit over te gaan als er geen performance winst uit te halen is? Vooral voor de thuismarkt is dit dan niets, aangezien die toch nog lang niet meer dan 4GB aan hoeven te spreken.
En die geintegreerde geheugencontroller werkt ook bij 32-bit, dus heeft 64-bit er geen extra profijt van...

[Wouter Tinus]

Tenzij je als consument met meer dan 4GB geheugen wil werken of veel met grote getallen doet (encryptie e.d.) heb je inderdaad weinig aan een 64-bit processor op zich. De meeste mensen die een Athlon 64 of een toekomstige 64-bit desktopchip van Intel zullen kopen willen gewoon snellere performance met hun huidige software, en dat kunnen Intel en AMD ook wel leveren met een 32-bit Hammer en 32-bit Prescott. Het "64-bit" klinkt allemaal wel leuk in de specs enzo, maar wordt pas in de toekomst echt nuttig. Gezien het aantal jaren dat zo'n project loopt is het natuurlijk vanuit de producent gezien wel verstandig om ruim op tijd te beginnen met zo'n overstap .

[Hielko]

Ik denk dat je vergeet dat AMD het aantal general purpose registers heeft verdubbelt bij x86-64 waardoor je ook met oude 32-bit software een prestatie winst kan verwachten als je tenminste een 64-bit OS gebruikt (als ik me niet vergis)

[Jit]

Helaas is de 4GB-grens niet helemaal correct op een x86.
In wezen moeten er al vanaf 1GB truukjes uitgehaald worden om geheugenadressering goed te kunnen doen.
Die truukjes (PAE) kunnen de boel dan wel oprekken tot 64GB, maar zorgen tevens voor een forse vertraging van geheugentoegang als je ze moet toepassen.

Zoals miw hieronder al aangeeft is op dit moment 512MB al bijna de gangbare hoeveelheid RAM in een nieuwe pc en ik denk dat we tegen het einde van dit jaar al wel eens richting die 1GB voor de enthousiast-pc gaan.

* 786562 Jit

[^Mo^]

zegt de 'grens' 640 K je nog iets?

Zegt 1200 euro je iets? Da's ongeveer de prijs van 4 x 1GB ECC registered geheugen.
Het gaat nog wel een aantal jaartjes duren voordat de consument daadwerkelijk meer dan 1 GB geheugen gaat gebruiken als standaard.

[Anoniem: 44174]

Dat zei men tegen mij ook toen ik 64 M in mijn pentium II 233 MHz systeem plaatste, echter 3 jaar later was het al normaal. Ik heb nu 1,5 GB in mijn huidige systeem zitten, datvinden de meeste mensen veel, maar dat zal over drie jaar ook weer normaal zijn en de prijzen dus ook.

[MacD]

Je berekeiningen worden precieser. Bijvoorbeeld als je in 3d een kleur moet berekeken; als je twee 64-bit getallen vermenigvuldigd en het antwoord terugschaalt is dat getal precieser dan wanneer je twee 32-bit getallen vermenigvuldigd.

[Luxx]

Ik denk dat je vergeet dat AMD het aantal general purpose registers heeft verdubbelt bij x86-64 waardoor je ook met oude 32-bit software een prestatie winst kan verwachten als je tenminste een 64-bit OS gebruikt

helaas, alleen met een 64bit applicatie op ene 64bit OS kan je deze gebruiken, klik

[boner]

Vooral voor de thuismarkt is dit dan niets, aangezien die toch nog lang niet meer dan 4GB aan hoeven te spreken.

zegt de 'grens' 640 K je nog iets?

@ ^Mo^
Toen de PC net uitkwam, ja toen was ik al ICT-er, kostte het ongeveer evenveel als die 1200 euro die jij noemt.....

[miw]

Een redelijk systeem heeft nu zo'n 512 MByte. Met een verdubbelling van geheugen grootte per jaar, heb je dus over drie jaar 4 GByte in zo'n standaard PC-tje zitten. Voor high end PC's breik je dat punt al eerder. Waarschijnlijk heb je al eerder 64 bit adressen nodig als je ook de I/O memory mapped wil doen.

[SG]

met 'n 32 bitter kan je ook 64bit proscessing doen alleen moet ie dat in stukken doen van 32bit

_int64 of double doet 'n 64bitter in één slag, 32bitter doet dat in twee

32bit waardes zijn ze weer even snel in op puur 32/64 vlak

in een van de revieuws is een LOW level synthetische bench gedaan waar de winst 4,54x is.

alleen is in reallife apps de applicatie code 'n mix bag, wat dus in houd dat je daar niet veel van terug ziet dus reallife 2 tot 30% winst afhankelijk van de Code mix.

[Anoniem: 74500]

Idd, maar nieuwe software zal waarschijnlijk meer en meer puur 64bit worden, aangezien binnenkort dus alle procs 64bit zullen ondersteunen.
Ook een 64bit-OS zal ervoor zorgen dat de prestaties in het totaal beter zijn, aangezien het de cpu minder belast.

Als je op www.tomshardware.com bij het artikel over de opteron kijkt, zie je dat in SUSE-64bit de opteron zeer goed presteert, ondanks de lage kloksnelheid. In de benches onder XP (32bit), nl. workstation-benches, verliest hij echter telkens van Intels (vaak maar met een klein verschil maar toch). Dus die 64bit maakt echt wel wat uit, en zal nog veel meer gaan uitmaken in de toekomst als meer en meer software puur 64bit wordt!

[n-i-x]

de Athlon64 heeft ook meer, en grotere registers, die(je raad het al)alleen in de 64-bit modus gebruikt worden.

Intel kan meerdere redenen hebben om dit uit te schakelen:
1. om de itanium niet voor de voeten te lopen.
2. omdat er dan veel errder optimalisaties voor komen, waarvan AMD meeprofiteerd.
3. om nog iets achter de hand te houden(net zoals ze met HyperThreading deden).

[Puppetmaster]

het blijft voor intel wel een mes dat aan twee kanten snijd...
aan de ene kant zullen ze het liever niet doen omdat ze dan het erg dure Itanium-project schade aan kunnen doen, maar aan de andere kant zullen ze de boot niet willen missen als blijkt dat x-86-64 erg populair blijkt...
ik vraag me af of ze uberhaupt wel x86-64 zullen implementeren of gewoon weeer hun eigen versie. als ze dat doen EN het lukt ze marktaandeel van AMD terug te winnen is AMD ECHT zuur!

[The Source]

Hoe kan Intel een eigen versie van x86-64 implenteren als tegen die tijd verschillende OS'en (windows, linux) en veel software geoptimaliseerd is voor de AMD versie van x86-64. Het zal altijd compatible moeten zijn (afgezien van de interne werking) omdat het anders geen nut heeft.

[SG]

Dan wordt linux en vooral MS ook gepushed om een intel x86-64 variant dus dan krijg je
Os varianten.
IA32
IA64
AMD64(x86-64)
intel64(x86-64)

en elk in eventuele optionele verschillende home prof server Advserver data center versies.

Microsoft staat daar niet op te springen.
Intel wel die wil graag de markt naar zich trekken met een direct concurrerende platform

[TheEagle]

Die OS'en kunnen natuurlijk ook net zo makkelijk weer overgezet worden naar Intels x86-64.

[TGEN]

Mja, ergens bij Sun (in de reality-check) kan je een bestinteressant artikel lezen over de sombere toekomst van de Itanium(2). Natuurlijk moet je een flinke zak strooizout achterover slaan als je het leest, maar de auteur heeft een aantal goede punten. Het maken van een, waarschijnlijk incompatible met x86-64 en ia64, cpu, is mijns inziens de volgende hindernis voor acceptatie van de Itanium. Daarbij komt, dat Intel met dit soort berichten zichzelf onbetrouwbaar maakt, aangezien afnemers van zijn producten niet meer kunnen rekenen op een lange houdbaarheid van het platform. Ik zie dit steeds meer in t voordeel van AMD omslaan, hoewel dat jammer is, want de Itanium is zeker geen lelijk eendje wat architectuur betreft. Het is vooral hard voor Intel omdat de Itanium2 al in testopstellingen is te bezichtigen, en de concurrentie dus weet waar ze aan toe zijn.

Ik zie het allemaal met argusogen aan...

[Yucko]

Ik dacht destijds te hebben gelezen dat ze (lees: Intel) claimden dat de P4 tot 10ghz zou (kunnen) doorschalen

[Wouter Tinus]

De Pentium 4 architectuur (P7) ja, maar de vierde of vijfde generatie daarvan zal waarschijnlijk pas zo ver komen. Als marketing er een andere naam voor "verzint" (Pentium 5 bijvoorbeeld) wil dat niet zeggen dat het een compleet nieuwe architectuur is.

[Sjah]

Ik denk dat je mag aannemen dat de veranderingen die ik las en zag, genoeg aanleiding voor Intel zijn om te zeggen dat Netburst Architecture van de P7 nu een gepasseerd station is, maarja dat is aan Intel natuurlijk. Andere reden om dit te denken is dat AMD nu naar de K8 is, en Intel niet wil "achterblijven", denk ik. Is het niet bij de Prescott, dan zal 't toch zeker wel bij de Tejas raak zijn(P8 wordt uitgeroepen). En dat zitten we nog ruim onder de 10Ghz.

[mr._Anderson]

Als Intel inderdaad dezelfde techniek als AMD gaat gebruiken, kan AMD dan niet van Intel eisen dat deze geld moet betalen aan AMD voor het gebruik van techniek wat door hun is ontworpen???

Dan zou AMD een hele goede winst erop na kunnen houden...

[reactie op Wouter Tinus]
het zou natuurlijk ook te mooi om waar te zijn geweest, en vanuit het oog, geven en nemen, is het natuurlijk ook altijd beter maar niet dit soort acties te ondernemen, zoals jij al zegt, ze zouden het hard op hun bord terug krijgen inderdaad
[/reactie]

[Wouter Tinus]

Hehe, AMD betaalt juist geld aan Intel om x86 te mogen gebruiken. De x86-64-uitbreiding is zoals in de nieuwspost staat vrij te gebruiken voor iedereen. Ze kunnen wel ineens geld eisen van Intel (als Intel het überhaubt willen gebruiken), maar ik voorspel dat ze dat dan bij de volgende onderhandelingen om de x86-licentie keihard terug op hun bord zouden krijgen.

[Blaah]

Volgens mij kan Intel het zich niet veroorloven om te gretig geld te innen voor alle technologieen waar ze patent op hebben, omdat ze dan snel de kartelwaakhonden op hun nek krijgen. Kijk maar hoe microsoft wordt aangepakt door de diverse instanties.

Wat dat betreft speelt Intel een subtiel spel: ze moeten AMD naast zich laten bestaan om geen monopoly-positie te krijgen terwijl AMD weer niet te sterk mag worden als concurrent. Misschien is het zelfs zo dat ze goed in staat zijn om mee te komen met AMD maar zullen ze dit nu laten omdat dat de nekslag voor AMD zou betekenen, waarna ze ineens monopolist zouden zijn...

[bolleh]

das natuurlijk onzin, neem als voorbeeld rambus, die cashen ook flink met een aantal patenten voor hoe geheugen in elkaar zit. als intel niet wil dat amd x86 verder gebruikt dan kunnen ze dat bij de volgende licentie onderhandelingen gewoon verbieden, en dan heeft amd gewoon een gigantisch probleem

[hardwareaddict]

Speculeren is mooi, de reacties op de speculaties zijn echter niet helemaal correct.

1) 64 bits helpt enorm voor alle cpu intensieve taken, vandaar dat alle highend cpu's 64 bits zijn. 64 bits voor de gewone gebruiker gaat met name spelletjes sneller laten draaien.

De opterons daarentegen, die moeten concurreren met I2 pricerange $4000 per stuk en meer. De AMD64 alleen met 32 bits processors, die natuurlijk worden weggeveegd (op voorwaarde dat de processor snel naar de 2.4Ghz doorklokt in 0.13).

Ervanuitgaande dat opteron en prescott tegelijk uitkomen in 0.09 ergens in 2004 (intel haalt dat nooit om prescott in de winkel te hebben liggen voor 2004), is het interessant ze te vergelijken.

Ten eerste was hier zopas het gerucht dat de prescott 4 instructies per clock effectief zouden kunnen uitvoeren. Dit zou een theoretische IPC van 4 geven dus. Dat wordt echter hard tegengesproken. Dat het ding een beetje 64 bits lijkt is logisch, daar er ook zo iets is als floating point en SSE2, wat tenslotte de voornaamste reden is dat de P4 het beter doet op specint als de AMD K7.

In dat opzicht ziet het ernaar uit dat Prescott niet vreselijk veel beter wordt, uitgaande dat het ding ook nog een max IPC heeft van 3. Execute het ding namelijk wel 4 instructies per clock, dan staan een hele berg intel experts in hun hemd. Die claimen van niks te weten.

Misschien is prescott 15% sneller als de P4 en dat zet niet zoveel zoden aan de dijk, want alles gaat natuurlijk 64 bits optimized worden. En juist dat is beretraag op een 32 bits cpu.

Dit waar de opteron/amd64 in 0.09 tot zijn recht komt en alle spelletjes, databases en andere cpu intensieve taken vreselijk snel gaat draaien. Dat voor een prijs die onder de P4 en zeker onder die van de prescott ligt.

Pas vanaf 4 en 8 cpu capable opterons is het uiterst onduidelijk wat de prijs gaat worden. Die nemen het dan ook op tegen processors als de 1.0Ghz itanium2 (McKinley). Een dual 1Ghz Itanium2 is te verkrijgen voor ongeveer 67000 dollar.

MVG

[Femme]

1) 64 bits helpt enorm voor alle cpu intensieve taken, vandaar dat alle highend cpu's 64 bits zijn. 64 bits voor de gewone gebruiker gaat met name spelletjes sneller laten draaien.

Het is hierboven en in talloze eerdere reacties ook al uitgelegd: 64-bit helpt alleen als er meer dan 4GB geheugen geadresseerd moet worden, of wanneer er met 64-bit getallen gerekend moet worden Dat laatste komt alleen in een aantal zeer specifieke toepassingen (zoals encryptie) voor. 64-bit code is groter dan 32-bit code en daardoor trager (omdat er meer cache en meer cache/geheugenbandbreedte wordt gebruikt) als de bovenstaande twee voordelen niet benut worden. Ook op 64-systemen wordt daarom bij voorkeur met 32-bit instructies gewerkt als 64-bit niet nodig is.

In het geval van AMD64-processors is de 64-bit modus wel sneller omdat er meer registers beschikbaar zijn, maar dat heeft niets te maken met het verschil tussen 32-bit en 64-bit.

[hardwareaddict]

Mag ik je herinneren aan SSE2 dat sneller is voor streaming en video games *omdat* het 64 bits is en niet 32 bits?

Zelfde gaat op voor 64 bits.

Het is triviaal dat op 64 bits alle cpu intensieve taken sneller gaan lopen. Zo triviaal dat ik niet begrijp dat sommigen zeggen dat we 64 bits niet nodig hebben.

a) databases
b) alle spelletjes
c) video
d) rendering
e) floating point
f) matrix calculaties

Noem maar iets op waarvan je *gokt* dat het niet profiteert van 64 bits.

Lees op AMD.com maar over hoeveel bytes 64 bits per instructie is voor de opteron. het is niet veel groter als 32 bits simpelweg.

Dat loopt niet *trager* ofzo.

Dat 64 bits instructies op de opteron licht trager zijn als 32 bits instructies is geen nieuws. Op de K7 zijn 8 bits instructies ook vet sneller als 32 bits instructies.

Dat is marginaal t.o.v. de snelheidswinst die 64 bits oplevert ook als je maar 128MB ram hebt

Wat wel zo is, is dat heel veel software herschreven en hercompileert dient te worden. Dat is *niet* triviaal. Vaak wil men 1 executable releasen die dan overal op loopt. Dat gaat natuurlijk met die architecturen die nu enorm uit elkaar gaan lopen, enorm lastig worden.

Ook als je kijkt op specint zie je simpelweg hoe de software van de opteron profiteert. Dit waar het ding enorm laag geclocked is, zelfs t.o.v. de K7.

Dat vertelt wel iets over de opteron.

Het smoesje hanteren dat we geen 64 bits nodig hebben maar wel met 8 bits kunnen volstaan, is natuurlijk te lachwekkend voor woorden.

[EXX]

Dat Prescott Pentium5 gaat heten lijkt me vrij waarschijnlijk; dat van Pentium 6 niet. Zo snel zullen de nummers elkaar niet opvolgen lijkt me.

Een andere optie is dat Prescott nog Pentium 4 blijft, en Tejas Pentium 5 wordt.

[voodooless]

Als Intel al AMD 64-bit x86 extensies gaat overnemen zal dat volgens de tabel pas in de P6 zijn omdat pas vanaf dat punt 16 registers (die de Athlon64/Operton nu al heeft) beschikbaar zullen zijn. Voor die tijd zal er dus geen binaire compatibiliteit zijn als de het toch zouden inbouwen.

Edit: Natuurijk kan Intel ook in de P5 de 64 bit extensies inbouwen, echter zijn de proggies dan niet binair compatible en door het gemis van 8 extra registers gaat een heleboel performancewinst verloren.

[The Source]

Wat enorm gek is dat AMD enorm veel patenten aanvraagd echter blijkt dat x86-64 vrij te gebruiken is. Waarom dat niet patenteren en daar licentie kosten voor in rekening brengen? Dat doet intel immers ook met de licenties van de x86 architectuur.

[Wouter Tinus]

Zijn meerdere redenen voor te bedenken natuurlijk. Anderen die jouw architectuur steunen kunnen handig om je eigen positie te versterken, en om jouw idee als (defacto) standaard te laten gelden. Denk aan steun van bedrijven als Transmeta en VIA. Niet heel veel indrukwekkends natuurlijk, maar toch weer een beetje gewicht in de schaal als Intel een eigen standaard zou proberen door te drukken.

Het zou echter ook onderdeel van het contract tussen Intel en AMD kunnen zijn. Een clausule die stelt dat eventuele uitbreidingen of verbeteringen die AMD doet aan Intels x86 instructieset openbaar beschikbaar moeten zijn, lijkt me helemaal niet onrealistisch.

[Anoniem: 25844]

weet iemand waar dat lijstje met software staat dat al klaar is voor de Opteron? volgens mij was het een artikel van Anandtech, ik kan het nergens meer vinden. Zou iemand mij de URL kunnen mailen; [e-mail]

groetjes Chris

[hardwareaddict]

Heel veel ontwikkelaars die ik althans ken hebben of al een opteron preordered of schaffen er snel 1 aan. Gemiddeld verwacht men volgende versie eind 2003 te releasen. Sommigen begin 2004. NUMA versies die op dual NUMA systemen vet sneller draaien, zullen wellicht langer op zich laten wachten.

Let wel op dat op dual systemen van de opteron de verwachting werd uitgesproken dat gigabyte moederbord niet NUMA is. Als dat zo is, dan is dat niet zo fijn voor de performance.

Verwachte speedup voor spelletjes ligt rond de factor 2 tot 4 wegens meer registers en 64 bits en een heel veel snellere memory toegang.

Alleen al die 64 bits levert soms al factor 2 op.