Vergelijking AMD64 en Intel CT 64-bit uitbreidingen

Op het Forum van Ace's Hardware is een interessante post verschenen van Hans de Vries waarin AMD's x86-64 instructieset vergeleken wordt met Intel's CT 64-bit-extensies. Hoewel Intel er geen ruchtbaarheid aan geeft zijn beide instructiesets grotendeels identiek en dus compatible met elkaar. Het enige verschil tussen beide instructiesets is de zogenaamde CMPXCHG16B-instructie. Hiermee kunnen Intel-processors twee registers met elkaar vergelijken en afhankelijk van de uitkomst wat husselen met de inhoud van bepaalde registers. Hiermee kan de 64-bit implementatie van Intel in theorie relatief iets sneller zijn dan AMD's implementatie, maar aangezien veel meer factoren invloed hebben op de prestaties is het nu nog veel te vroeg om hier uitspraak over te doen. Invloed op de compatibiliteit zal de extra instructie in ieder geval niet hebben.

Reacties (31)

Het enige verschil tussen beide instructiesets is de zogenaamde CMPXCHG16B-instructie.

Wat een ellende. Standaarden uitbreiden. In de marketingwereld beter bekend als "embrace and extend". Intel lijkt Microsoft wel, die dat ook veelvuldig heeft gedaan. Een standaard omarmen, deze een klein beetje aanpassen, en ondertussen alle toepassingen dat kleine beetje verschil laten gebruiken. Dit wordt vaak gedaan als een andere kleine speler iets eerder heeft uitgevonden dan de grote speler. Ik was er al bang voor!

Het mooie van standaarden wordt weer mooi om zeep geholpen, het punt is dus dat je nu niet meer op x86-64 kunt controleren als je iets lekker in assembly aan het prakken bent. Nee je mag weer lekker alle processorspecieke dingen controleren.

Het is hetzelfde als AMD SSE2 zou uitbreiden met 1 instructie. Alleen AMD heeft niet, i.t.t. Microsoft en Intel, de macht om het te gaan misbruiken.

Dat nog niemand hier in deze thread er iets over heeft gezegd!?

Misschien zie je meer problemen dan er zijn. Als jij zo graag perse in assembly wilt programmeren is er niemand die je verplicht om deze extra instructie te gebruiken. Als je gewoon in een hogere level taal programmeert dan zorgt de compiler er wel voor dat het goed gaat.

Assembly was natuurlijk een voorbeeld. Nog een voorbeeld, alle compilers zullen speciaal voor CT moeten worden omgeschreven, tenzij iedereen de schurft heeft aan Intel's extra instructie - op de Intel compiler na. Ik ben zeer benieuwd of de Intel compiler code kan compileren voor AMD64 of dat ze door middel van deze extra instructie de Intel compiler Intel-only houden.

Het is toch een goed recht van Intel om een "zwak punt" in AMD64 te verbeteren voordat ze het overnemen? Intel ziet blijkbaar grote voordelen in het gebruik van deze instructie. Intel maakt zelf compilers, dus ieder stukje software kan deze instructie makkelijk gebruiken, of (door het gebruik van een andere compiler) niet. De MS compiler (die voor het windows gebeuren de meeste software zal compilen) zal heus wel snappen of je deze instructie wilt/kunt gebruiken, of niet.
Ook de open source wereld is zelf slim genoeg om uit te zoeken hoe ze hier winst uit kunnen halen, zonder AMD direct te benadelen.

Zolang Intel geen grote software bakker is, zie ik het probleem van dit soort acties niet (als Intel nou MS zou overnemen, of andersom), dan zou dit vervelende situaties kunnen opleveren. Maar in dit geval is er niet veel aan de hand. Intel heeft zo veel instructies toegevoegd aan de originele IA32 instuctieset deze is in princiepe niet anders dan al die andere...

Het is toch een goed recht van Intel om een "zwak punt" in AMD64 te verbeteren voordat ze het overnemen?

Tuurlijk, ik zeg ook niet dat ze het niet mogen doen.

Intel ziet blijkbaar grote voordelen in het gebruik van deze instructie.

Yep, maar ik denk dat er grote kans is dat dit idee om een instructie toe te voegen uit de marketinghoek komt. Naar buiten zullen ze het natuurlijk communiceren als een verbetering. Precies zoals Microsoft. Microsoft heeft HTML immer ook "verbeterd". Waarschijnlijk zullen de gevolgen door het uitbreiden van x86-64 lang niet zo groot niet als wat Microsoft gedaan heeft met HTML, maar dan nog, het is gewoon een goed voorbeeld wat een "verbetering" soms teweeg kan brengen.

Intel maakt zelf compilers, dus ieder stukje software kan deze instructie makkelijk gebruiken, of (door het gebruik van een andere compiler) niet. De MS compiler (die voor het windows gebeuren de meeste software zal compilen) zal heus wel snappen of je deze instructie wilt/kunt gebruiken, of niet.
Ook de open source wereld is zelf slim genoeg om uit te zoeken hoe ze hier winst uit kunnen halen, zonder AMD direct te benadelen.

Tuurlijk, alles is mogelijk, maar blij zullen ze niet zijn. Verre van dat.

Zolang Intel geen grote software bakker is, zie ik het probleem van dit soort acties niet (als Intel nou MS zou overnemen, of andersom), dan zou dit vervelende situaties kunnen opleveren. Maar in dit geval is er niet veel aan de hand. Intel heeft zo veel instructies toegevoegd aan de originele IA32 instuctieset deze is in princiepe niet anders dan al die andere...

Ik dacht dat AMD volledig compatibel is met IA-32 en met de AMD64-processors ook alle extra instructiesets als SSE, SSE2, enz. ondersteunt, behalve SSE3. Het niet ondersteunen van SSE3 vind ik een heel ander verhaal dan het met opzet incompatibel maken van een instructieset.

Hiermee kan de 64-bit implementatie van Intel in theorie relatief iets sneller zijn dan AMD's implementatie, maar aangezien veel meer factoren invloed hebben op de prestaties is het nu nog veel te vroeg om hier uitspraak over te doen.

Inderdaad, het zou heel goed kunnen dat een paar functietjes bij AMD wat efficiënter geïmplementeerd zijn en dat dat het verschil bij Intel vrijwel volledig of misschien meer dan teniet doet. Je kunt er echt helemaal niets over zeggen totdat je het in de praktijk kunt testen.

Is er behalve de instructiesets nog meer bekend zoals instructions per cycle van de beide dingetjes? Dat zal wel zo'n beetje doorgaan zoals het nu al gaat op de roadmap neem ik aan?

Echt veel verschil was ook niet te verwachten. x86-64 is al als standaard geaccepteerd door grote hard- en software bedrijven. Het beste voorbeeld is denk ik Microsoft dat geen 4e platform wil gaan ondersteunen.

Ik ben wel benieuwd naar de performance van de Xeon met 64bit uitbreiding. Verschillende benchmarks laten zien dat de Athlon64 en de p IV met 32bit aplicaties elkaar niet heel veel ontlopen. Ondanks dat beide implementaties niet veel van elkaar verschillen, en dus klok-voor-klok niet veel performance verschil zouden moeten laten zien, is er wel een groot verschil in kloksnelheid. De Athlon en Opteron draaien op veel lagere kloksnelheden dan een vergelijkbare p IV. Ik ben beniewd of het voordeel dat AMD heeft (vergelijkbare performance bij een lagere kloksnelheid zie ik als een voordeel) ook bij 64bit aplicaties aanwezig is.

@hardwareaddict

Ik las anders laatst op Tweakers dat Microsoft pas onlangs besloot om het bij de huidige 3 platformen te houden. Dat was omdat de CEO van AMD ten gunste van Microsoft had getuigd bij 1 van de vele anti-trust rechtzaken.

Ik vermoed dat AMD inderdaad sneller was doordat Intel zich in eerste instantie op Itanium heeft gericht. Toen het duidelijk werd dat x86-64 wel eens een succes zou kunnen worden heeft Intel de bestaande plannen wat moeten versnellen. Maar dat zijn slechts speculaties.

Dit is al jaren geleden besloten natuurlijk. Je ontwikkelt niet zo maar een CPU. Mijn vermoeden is dat AMD sneller hun opteron af hadden als INTEL de nocona.

Historisch interessant is om te weten wanneer intel begonnen is met deze nocona chip te ontwikkelen. Dat zou een leuk licht schijnen op de zaak.

Wel was het al 8 maanden geleden duidelijk dat ze een x86-64 zouden maken, maar ook ondergetekende had hem niet voor begin 2005 verwacht.

Nu gaat het interessant worden om te zien of intel weer de keuzefouten gemaakt heeft die ze bij de P4 en itanium gemaakt heeft. Namelijk superkleine L1 cache die de grootste bottleneck vormt in veel complexe software.

In elk geval is het nu heel duidelijk welke bepaalde welbekende heren, die tot voor kort nog zeiden: "intel gaat never nooit x86-64", in het vervolg met een korreltje zout genomen dienen te worden.

Hoe de chip gaat presteren is natuurlijk super onduidelijk tot zijn specificaties bekend zijn.

Zelfs de specificaties van de prescott op wat lezingen klopten niet, zo ad hoc worden er momenteel door intel beslissingen genomen t.a.v. processors.

In elk geval een mega prestatie van Intel om op zo'n voor processor ontwikkeling korte termijn een nieuwe chip neer te zetten!

"jaren", mwa. Dit zal wellicht (net als bij AMD) meer evolutionair zijn dan revolutionair: het is geen nieuw ontwerp, maar een aanpassing van het bestaand ontwerp van 32 naar 64 bit. Net zoals de AMD64 eigenlijk nog grotendeels een Athlon (K7) is.
AMD64 zou je beter als K7+ kunnen zien.

Dacht zelfs dat AMD zelf de term "K8" pas voor de volgende generatie gepland had.

Nocona / Prescott zijn gewoon een doorontwikkeling van de vorige Pentium 4/Xeon cores. Hetzelfde helft voor de K8-familie ten opzichte van de K7, al heeft AMD daar nog wat radicalere veranderingen aangebracht (HyperTransport, geïntegreerde geheugencontroller).

Bij Hans de Vries kun je wel een foto opvragen dan zul je stevige verschillen zien hoor

Als je alleen al het aantal transistors van de K7 afzet tegen de K8, dan is dat al veelzeggend

Het is zelfs zo erg in hardware dat bij een nieuwe proces technologie *alle* transistors weer overnieuw berekend en geoptimaliseerd dienen te worden.

De optimalisatie van alle chips wordt met de hand gedaan daar hoog clocken van de chips belangrijk is.

Grotere BPT bijvoorbeeld betekent dat alle core logics overnieuw ontworpen dient te worden.

De K8 heeft 16384 BPT entries versus K7 heeft er 2048.

De K7 is 32 bits @ 0.13, terwijl de K8 dieper gepipelined is en berekend op doorclocken in 0.09, kortom de hele core is overnieuw ontworpen.

Natuurlijk ontkomen de cores niet aan het uitvoeren van x86 instructies. De logics van de 64 bits is echter veel groter en de L2 cache is 2x groter.

Hetzelfde geldt voor Nocona.

Noobvraag misschien, maar BPT entries. Ik snap meer / andere logica en schakelingen, maar BPT entries is nieuw voor me

een gokje: Branch Prediction Tables?

Dit zijn totaal nieuwe chips hoor. Nocona en Opteron lijken in de 64 bits met geen mogelijkheid op andere amd/intel chips.

naja, de x86-64 of AMD64 (hoe je het ook maar wil ) standaard is al een aantal jaren bekend en open dachtik...
het is idd interessant te weten hoe lang ze er al mee bezig zijn, al kan dat dus al vrij lang zijn....

(wel korter dan AMD, maar die hebben ook best lang met de on-die mem controller zitten klooien dachtik)

[edit]
ach, 2004-1999= 5 (iets minder door oktober)
en ik vind >3 wel genoeg voor "jaren"
http://www.amd.com/us-en/Processors/ComputingSolutions/0,,30_288_1907_

Het is niet open standaard natuurlijk, maar intel hoeft er niet voor te betalen daar ze ze kunnen uitwisselen voor x86 patenten wat ook al enige tijd geleden gedaan is.

Erg interessant gaat worden of intel AMD weet te overtreffen, met name op L2 cache gebied.

Op dit moment is de opteron daar dominant. 1MB L2 cache die binnen 13 clockcycles tot je beschikking staat.

en wat veel mensen niet doorhebben is dat amd de geheugen controller nog op de cpu zelf heb zitten, wat dus nog steeds een snellere oplossing is als de xeon,

wat me wel weer zorgen baart is dat de Xeon al zo geaccepteerd is (je ziet ze overal in het bedrijfsleven) dus zal AMD erg hun best moeten doen!

Tja, voor de ene is service belangrijker als snelheid.

Een ieder moet dat voor zich afwegen.

Intel was een aantal jaar geleden gewoon *dominant* qua prestatie en prijs.

Dat is alleen dankzij hard werk bij AMD nu wat competatiever geworden. Niet iedereen volgt de markt echter erg goed.

Zo vragen sommigen zich af waarom ik van die hoofdletter K harddisks hier heb i.p.v. alleen Seagate Barracuda's (die aanzienlijk minder geluid produceren als andere harddisks). Dat wist ik dus toen ik ze kocht weer niet!

Het gros van de wereld ziet een 3.2ghz P4 Xeon versus een 2.2Ghz opteron. Dan weten ze wel welke processor ze nemen. Ik neem dat niemand kwalijk.

Intel is nu alleen nog dominant in haar service + marketing.

Ik denk dat het eerder te maken heeft met aanbod.
Hoeveel keus heb je als je een professionele server wilt hebben ? 9 van de 10x kom je alleen Xeon's tegen. Dus hoe kan een klant kiezen als je alleen Xeon's kan kopen ?

IBM, HP, Dell etc zijn belangrijke spelers zij leveren de meeste servers, pc's en support voor de zakelijke markt en op IBM na zijn ze allemaal intel only wat x86 servers betreft.

Dat is waarom mensen geen AMD kopen, niet omdat ze het niet willen maar omdat het niet te koop is bij de grote jongens. De meeste pc kopers etc zijn een heel stuk objectiever dan wij tweakers die duidelijk een voorkeur hebben. Waarom is marketing nodig als mensen toch allemaal een intel willen ? Juist, de grootste groep neemt gewoon wat er te koop is, en intel zorgt er juist voor dat die mensen alleen intel kunnen kopen.

Een server bestaat uit meer onderdelen dan een processor alleen, en support wordt op de servers geleverd en niet op de processor en intel verkoopt geen pc's of servers, de meeste problemen zijn toch nooit processor gerelateerd. Het zijn alijd andere componenten die voor problemen zorgen ongeacht platform.

Videokaarten bijvoorbeeld, de grootste problemen komen altijd van de koelers of geheugen chips, en een zeeer enkele keer de grafische chip zelf. Dus dat van support is eigelijks juist de grote toko's die er achter staan. IBM zal volledig support leveren op hun Opteron servers, en dat zal niet anders dan de support voor IBM's Xeon servers zijn.

Iig hebben de klanten van IBM nu een keus, ik ben benieuwd hoe het zal gaan lopen.

Door de CMPXCHG16B-instructie te verwerken in toekomstige applicaties is het mogelijk om AMD-processors uit te sluiten voor deze applicaties ?

btw, laat maar zitten, lijkt me sterk...

Nah, gelukkig zijn programmeurs doorgaans slim genoeg om een test te doen of de extensie ondersteund wordt in de processor, voordat ze hem gebruiken.

sterker nog dat wordt meestal ook al gedaan (denk aan mmx sse en sse2)

Invloed op de compatibiliteit zal de extra instructie in ieder geval niet hebben.

Tuurlijk wel! Op dezelfde manier als wanneer Intel 1 instructie van de AMD instructieset niet zou ondersteunen.

Nee alleen als het vergelijken en husselen van registers met omwegen niet nagebootst kan worden dan zal het niet compatibel zijn.. Anders kan alles gewoon werken, hetzij iets langzamer.

Dat maakt niet uit, de instructieset blijft gewoon incompatibel, het is dan alleen een work-around voor niet-compatibel code zodat die op incompatibele processoren toch te draaien is.

Dat iets werkt zegt niets over compatibiliteit.

Dus jij wil zeggen dat een powerpc, ultrasparc en Athlon64 compatible zijn? Je kunt immers alle 3 alles doen... Volgens mij is het moeten maken van een omweg (of het soms kunnen gebruiken van een short-cut) juist iets wat je incompatible noemt.

Geruchten gaat rond dat Intel een AMD heeft lopen door te zagen om zo de 64bits implementaties te doorgronden.
Vandaar dat het even duurde.

Natuurlijk bekijken alle fabrikanten elkaars chips tijdens de koffiepauze, maar dit soort onzin postings doen met volledig uit de lucht gegrepen beschuldigingen is niet handig.

Als je dit in een officiele setting zou doen, dan had je nu dus 5 rechtszaken aan je broek.

Het is toch geen officiele setting?
Waar maak je je zo druk om.. Iedereen weet dat het anders stelen is.. bedrijfsspionage etc etc.

offtopic /

ik vin dat altijd van die on overzigtelijke forums