Architectuur Intel Core en AMD K8 vergeleken

In een uitgebreid artikel heeft AnandTech de Intel Core-architectuur (Conroe) vergeleken met de AMD K8-architectuur (Athlon 64 en Opteron). De Core-architectuur kan beschouwd worden als Intels achtste generatie architectuur die voor een groot gedeelte gebaseerd is op de Pentium M-architectuur. Dat wil echter niet zeggen dat het een regelrechte kopie is, want 80% van het Pentium M-ontwerp is door Intel veranderd voor de Core-architectuur. Net als de Pentium M-architectuur combineert de Core-architectuur het beste van twee andere Intel-architecturen: de prefetchers en de bus zijn gebaseerd op de Netburst-architectuur, terwijl de rest van de processor een evolutie is van de Pentium Pro-architectuur.

Prefetcher en cachegeheugen

De prefetcher is verantwoordelijk voor het ophalen van instructies en gegevens uit het geheugen. Het is zijn taak om te zorgen dat de pipeline van de cpu gevuld blijft met instructies en dat deze instructies de gegevens ter beschikking hebben om mee te werken. De Core-architectuur heeft per core een prefetcher voor instructies en twee voor gegevens. Daarnaast beschikt de dualcore-implementatie van de Core ook nog eens over twee extra prefetchers voor het L2-cachegeheugen. De K8 heeft echter maar een prefetcher per core. Naast meer prefetchers heeft de Core ook meer L2-cachegeheugen ter beschikking. Opmerkelijk is dat de 4MB grote L2-cache in ongelijke stukken over beide cores kan worden verdeeld. Dit zou een groot voordeel kunnen zijn voor singlethreaded applicaties. De L1-cache is daarentegen twee keer zo klein als dat van de K8. Dit wordt echter goedgemaakt door het feit dat het 8-way associative is (Core) in plaats van 2-way voor de K8. De hitrate zou dan ook ongeveer hetzelfde moeten zijn.

Decoder

Na het prefetchen van instructies en data is het de taak aan de decoder om de instructies in kortere instructies (micro operations) op te delen. Dit zijn de instructies die uiteindelijk door de processor uitgevoerd zullen worden. De Core heeft hiervoor de beschikking over drie decoders voor simpele instructies en een decoder voor complexe instructies. De K8-architectuur heeft drie decoders die allen met complexe instructies overweg kunnen. Gezien het merendeel van applicaties uit simpele instructies bestaat, heeft de Core hier een voordeel.

Out of order execution

Zowel de Core als de K8 kan instructies in een andere volgorde uitvoeren. Om de resultaten hiervan bij te houden heeft de Core-architectuur de beschikking over een tabel met 96 velden, 16 meer dan de Pentium M en zelfs 56 meer dan de Netburst-architectuur. De K8-architectuur gebruikt een tabel met 72 velden. Hier staat echter tegenover dat de Core slechts maximaal 32 instructies kan herordenen en de K8 maar liefst 60. Toch lijkt het erop dat de Core in het voordeel is. Zo kan de Core maar liefst drie 128-bits SSE1/2/3-instructies tegelijkertijd uitvoeren, terwijl de K8 over slechts twee 64-bits SSE execution units beschikt. De Core zal volgens AnandTech bij het gebruik van SSE-instructies dan ook minimaal twee keer zo snel zijn als de K8. Voor het verwerken van drijvendekommagetallen is de Core op papier ook sneller, omdat die hiervoor vier eenheden ter beschikking heeft ten opzichte van drie eenheden voor de K8. Behalve dit alles kan de Core ook de volgorde van het uitvoeren van load- en store-instructies veranderen. De K8 kan dit echter niet.

Conclusie

Op papier heeft de Core een betere architectuur dan de K8. De eerste benchmarks hebben dit ondertussen ook bevestigd. Toch betekent dit niet dat de K8 een achterhaalde architectuur is. Op een aantal punten zou deze namelijk nog flink verbeterd kunnen worden. Meest voor de hand liggend is het verhogen van het aantal SSE-units en het verhogen van de bandbreedte van het L2-cachegeheugen. Daarnaast zou de out-of-order logica van de K8 verbeterd kunnen worden zodat loads en stores ook in een andere volgorde uitgevoerd kunnen worden.

Reacties (54)

[Roland78]

Ik vind AMD opvallend stil de laatste tijd. Zij moeten de gegevens uit het bovenstaande verhaal toch ook al lang kennen. Op basis van dit verhaal is het heel gemakkelijk om aan te geven waar de zwakke punten van de K8 ten opzichte van de Conroe/Merom/Woodcrest liggen.
Het lijkt me daarom een kwestie van (weinig) tijd voordat er een geüpdatete versie van de K8 architectuur klaarligt. Het zal niet veel tijd kosten, want: 1) er kan gebruik gemaakt worden van dezelfde productietechnieken, 2) de architectuur hoeft niet elementair te veranderen (alleen meer bandbreedte, andere sub-blokken), 3) AMD bezit al lang, veel kennis over de CMW-architectuur.
Het zou mij dus niet verbazen wanneer AMD haar K8L tegelijk met de Intel Core Duo 9000-serie uitbrengt en de hele hype rond deze fantastische nieuwe processor aardig kan counteren.

[Verwijderd]

Op basis van dit verhaal is het heel gemakkelijk om aan te geven waar de zwakke punten van de K8 ten opzichte van de Conroe/Merom/Woodcrest liggen.

Ja, maar de oplossing ligt minder voor de hand, dan op een simpel schemaatje zoals hierboven een paar extra componenten toe te voegen.
Om te beginnen kosten extra componenten extra tranistors. Hiervoor moet plaats gemaakt worden, want het heeft geen zin de extra componenten ergens in een uithoek van de chip te leggen. Hierdoor kan dan bv een klokcyclus verloren gaan omdat het signaal van de ene kant van de chip naar de andere moet reizen om een instructie uit te voeren (het duurt mss maar een honderdtal picoseconden, maar één klokcyclus duurt ook maar zo lang). Dat zou dus al betekenen dat de lay-out van de chip volledig moet aangepast worden.
etc etc...

[Verwijderd]

Denk je nou echt dat AMD binnen een paar maanden een grote revisie op de K8 kan ontwikkelen zonder dat er nu ook nog maar iets van bekend is?

Verder heeft AMD de stap naar 65 nm nog achter de hand. Ik neem even aan dat ze hier nog wel 0,4 GHz mee kunnen winnen. Een Dual Core K8 @ 3,2 of 3,4 GHz is natuurlijk niet bepaald langzaam.

AMD moet echter binnen een jaar ofzo wel met een verbetering komen. Quad core is natuurlijk leuk, maar dat kan Intel ook doen met Core.Maar op 4-way server gebied blijft AMD nog wel even de baas, en hier halen ze een relatief grote marge.

[martijnvanegdom]

Het zou wat zijn als de K8 architecteur op papier beter zou zijn dan de core architecteur! De core architecteur is ruim een ander half jaar jonger dan de K8 als ik me niet vergis.

Het werd eindelijk een keer van Intel.. ben erg benieuwd naar de volgende architecteur van AMD

[EnsconcE]

Het mooie van dit proces is, is dat het een wisselend proces is. Voor het ene jaar is intel beter, voor het andere amd. Dat komt omdat nu bijvoorbeeld de core een reactie is op de k8 en dat de opvolger van de k8 waarschijnlijk een reactie gaat zijn op de core.

Ik hou wel van concurrentie, gezonde concurrentie haalt het beste in beide bedrijven naar boven. Nu kijken wie het beste grafisch kan rekenen .

@Countes
En wat dacht je van de netburst, pentium pro en de pentium m?

[murtoz]

... is, is ...

... tsk, tsk ...

[Countess]

http://en.wikipedia.org/wiki/Opteron

april 2003 werd de k8 geintroduceerd
dus bijna exect 3 jaar op de markt. de conroe nogsteeds niet.
en aan het ontwerp werd al veel langer gewerkt.

[Niles]

Tja, als je de historie bekijkt, is Conroe gewoon gebaseerd op de P6 architectuur van Intel, die men ook gebruikte in de tijd van de Pentium 3 en die dus véél ouder is dan AMD's K8 architectuur. Conroe is gebaseerd op Yonah, en Yonah was gebaseerd op Dothan en Banias (beide Pentium M's) en deze twéé waren weer gebaseerd op de laatste generatie P3: Tualatin. Allemaal gebaseerd op de P6 architectuur dus . Tuurlijk is er veel aan veranderd, maar de basis ligt bij de P6.

[Wouter Tinus]

Langere pipeline, overgang naar 64 bit, bredere decoders, meer execution units en alles wat erbij komt kijken om die gevuld te houden, memory disambiguation, zeer agressieve power management, zwaar verbeterde caches, prefetchers, branch predictors... er is letterlijk geen spaan meer heel van de P6 hoor. Lees het originele artikel maar eens: zelfs ten opzichte van Yonah (die conceptueel nog het meest op Core lijkt) is 80% van het ontwerp veranderd.

Het is natuurlijk niet zo radicaal als Netburst destijds was, maar wie beweert dat Core een P6 is doet het ontwerpteam absoluut geen recht aan. Als je zo ver gaat generaliseren zijn alle processors gewoon hetzelfde: data en instructies gaan erin, hij rekent, en het antwoord komt eruit .

[mark_vb]

@ThaMind:

Het gaat er natuurlijk wel meer om waar de introductie van de huidige versie ligt. Aangezien de K8 ook gebaseerd is op voorgaande modellen, op die manier kun je terug blijven rekenen.

[Verwijderd]

De K8 is gebaseerd op de K7 die eigenlijk ook weer min of meer gebaseerd is de K6 etc. etc.
Uiteindelijk ligt de basis voor de meeste moderne chips (muv. netburst en de Itanium) ongeveer op dezelfde plaats.

[Verwijderd]

Tja, als je de historie bekijkt, is Conroe gewoon gebaseerd op de P6 architectuur van Intel, die men ook gebruikte in de tijd van de Pentium 3 en die dus véél ouder is dan AMD's K8 architectuur.

Nog ouder... Ook de Pentium Pro en Pentium II waren al gebaseerd op deze P6-architectuur (P6 is de codenaam van de Pentium Pro, P5 was de gewone Pentium).
De architectuur kwam dus al in 1996 op de markt.
Aan de andere kant is de K8 dus ook niet helemaal nieuw, maar is deze grotendeels gebaseerd op de K7. De ontwikkelaars van de K7 hebben op hun beurt goed naar de P6-architectuur gekeken. Het zijn duidelijk generatiegenoten, en zowel qua opbouw (pipeline-lengte en dergelijke) en prestaties lagen ze redelijk dicht bij elkaar.

[Verwijderd]

Het is natuurlijk niet zo radicaal als Netburst destijds was, maar wie beweert dat Core een P6 is doet het ontwerpteam absoluut geen recht aan.

Ja, dit gerucht deed al heel lang de ronde, en ik heb dat altijd al geprobeerd te ontkrachten.
Blijkbaar willen AMD-fans dit graag horen, omdat het een nogal negatieve bijsmaak heeft... Zo van "Intel moet een stap terug doen".
Maar nu de Conroe daadwerkelijk de eerste tekenen van leven heeft gegeven, is het eigenlijk niet zo relevant meer.
Laat iedereen maar beweren dat het een P6 is, je kunt toch niet om de prestaties heen, het is gewoon de beste x86-core die er is op het moment. Nu is het eerder negatief voor AMD... "Zelfs met een hele oude core verslaat Intel AMD nog".

[i-chat]

maar goed dat het al lang geen P6 meer is dan.....
das niet goed voor de intel fanboys en ook niet goed voor de amd-aanhangers,

dat zou namelijk betekenen dat er geen of nouwelijks nog vernieuwingen waren,

zeg nouw zelf: als AMD geen goede concurenten meer maakt heeft intel geen reden iets beters te maken en visa-versa, in alle gevallen slecht voor de consument die graag een nieuwere snellere beter presterende en vooral goedkopere computer wil.....

[EaS]

De tape-out ("design was af") van AMD's K8 was in november 2001. Dat maakt de K8 bijna 4 jaar (!) ouder dan Intel's NGMA.

[Wouter Tinus]

De architectuur ligt natuurlijk ook allang voor de tape-out vast. Een processor met een nieuw ontwerp op de markt brengen kost zo'n 4-5 jaar en de belangrijkste beslissingen moeten in het begin van dat traject worden genomen (voor Merom dus begin 2002). Op architectuurniveau bestaat er niet zoiets als een 'snelle reactie' op een product van de concurrent, je moet gewoon bidden dat je de juiste keuzes hebt gemaakt. Je kunt eventueel de introductie vervroegen door dingen te schrappen maar halverwege iets toevoegen is onmogelijk zonder heel veel uitstel. Intel heeft 'geluk' gehad dat ze naast Netburst nog een alternatieve serie in de pijplijn hadden. (Geluk tussen aanhalingstekens omdat het gewoon hun bedrijfsbeleid/cultuur is )

Maar goed, het zou inderdaad wel heel slecht zijn als Core niet beter dan K8 zou zijn. De vraag is alleen of en zo ja wanneer AMD soortgelijke keuzes heeft gemaakt. Dat ze uiteindelijk met iets beters dan Core zullen komen staat zo ongeveer vast, maar Intel blijft natuurlijk ook niet stilzitten. De roadmap voor nieuwe/verbeterde architecturen (Nehalem in 2008 en Gesher in 2010) is erg agressief. Hopelijk gaat AMD in juni eindelijk iets concreets vertellen over zijn plannen.

[Cookie]

Intel heeft 'geluk' gehad dat ze naast Netburst nog een alternatieve serie in de pijplijn hadden. (Geluk tussen aanhalingstekens omdat het gewoon hun bedrijfsbeleid/cultuur is

Bedrijfscultuur...misschien. Het 'handhaven' van PIII (in de vorm van een Tualatin) voor Mobile en Blades is gewoon een slimme/verstandige keuze geweest lijkt me. Wat ze daar hadden was te bruikbaar om weg te gooien. Verder: Pat Gelsinger wees in 2001 al op de limieten van een 'powerwall' waar men op af zou stevenen. Het lijkt erop dat al vroeg er een omslag t.o.v. Netburst dik in zou zitten. In ieder geval zeggen ze bij Intel nu dat ze alles inzetten op 1 core-ontwerp, voor mobile, desktop en server (hpc even niet meegerekend), dus dan zouden ze nu van hun geloof af zijn gestapt ?

[Wouter Tinus]

Prescott als ontwerp was in 2001 al 'well underway' (quote van iemand die er aan gewerkt heeft). Toen de doelstellingen (in 1999?) werden vastgelegd had men waarschijnlijk niet in de gaten hoe erg lekstroom zou worden bij die snelheid. De originele P4 was op dat moment nog niet eens af en het meest geavanceerde procédé dat ze hadden was 180nm, wisten hun veel . Blijkbaar dacht men toen dat men het allemaal wel onder controle kon houden met kleinere transistors, en voorzag men meer een lineare toename dan een exponentiële.

Dat het onmogelijk was om met deze lijn fatsoenlijke notebooks te maken had men in ieder geval snel genoeg in de gaten (getuige Pentium M), en het feit dat Merom (ergens in 2002?) al 64-bit gemaakt werd betekent doet toch vermoeden dat er toen al een soort Plan B in de maak was. Origineel wilde men het lnog een paar jaar langer uitzingen met Netburst, maar we weten hoe dat is afgelopen: de consument protesteerde te veel en toen kwam AMD nog eens met een ijzersterk ontwerp ook .

Dat er nu één core gebruikt wordt om meerdere segmenten te bedienen zegt trouwens niet per sé dat die 'cultuur' anders is geworden. Ik doelde niet op parallelle productlijnen, daar wilde men juist vanaf (het was niet leuk als bijvoorbeeld één team SSE3 of virtualisatie bedacht voor hun core, en het andere zich achter de oren moest gaan krabben over hoe ze dat nou weer in hun eigen core gingen stoppen). Ik bedoelde meer alternatieve interne ontwerpen die tegelijk gedaan worden. Recente voorbeelden zijn Whitefield -> Tigerton en 'oude' Tukwila naar 'nieuwe' Tukwila.

Intel laat vaak concurrerende teams aan projecten met dezelfde doelstelling werken zodat men dichter bij de introductiedatum een beslissing kan nemen over wat het beste pad is. Omdat Core feitelijk al Plan B is zal daar geen alternatief meer voor geweest zijn, maar het zou me niets verbazen als er op dit moment twee teams aan twee verschillende Geshers werken .

[EaS]

De architectuur ligt natuurlijk ook allang voor de tape-out vast.

Yep. Maar je moet toch ergens een punt op de tijdlijn nemen. Introductiedatum van een product zegt niet zo veel (daar spelen ook andere zaken mee).
Uitgaande van een ongeveer gelijke ontwerp tijd voor AMD en Intel, zegt mij een tape-out indicatie meer. De tijd tussen project start en tape-out zal, bij zowel AMD als Intel, ergens in dezelfde orde van grootte liggen. En dat verschil tussen Hammer en Core blijft dan toch ~3.5 a 4 jaar:

Tape-out Merom: Juni 2005
Tape-out Hammer: November 2001

Nemen we project start, uitgaande van gelijke ontwerp tijden voor een product, bij zowel AMD als Intel:
Intel Merom: 2002
AMD Hammer: 1998
Verschil wederom een jaar of 4.

Maar goed, het zou inderdaad wel heel slecht zijn als Core niet beter dan K8 zou zijn.

Inderdaad, dat was eigenlijk meer het punt. Maar vast staat dat Core een prima design is.

[RickDeckard]

Intel heeft 'geluk' gehad dat ze naast Netburst nog een alternatieve serie in de pijplijn hadden

Tsja, zo heeft AMD dan weer het 'geluk' gehad dat ze indertijd zowat het ganse DEC Alpha team hebben kunnen binnenhalen voor de ontwikkeling van de K7, wat toch wel de eerste lijn van AMD processoren was die de concurrentie met Intel kon aangaan.

[John_Glenn]

De L1-cache is daarentegen twee keer zo klein als dat van de K8. Dit wordt echter goedgemaakt door het feit dat het 8-way associative is (Core) in plaats van 2-way voor de K8. De hitrate zou dan ook ongeveer hetzelfde moeten zijn.

Jullie durven dit natuurlijk allemaal niet te zeggen, maar... leuk artikel, ...en ik begrijp er weinig van.

edit: mijn dank voor alle uitleg! Het is nu een stuk begrijpelijker.

[Countess]

simplere gezegt : de l1 cache van de k8 is 2 keer zo groot
maar de bandbreedt van de l1 cache in de conroe is 4 keer groter.

de hitrate heeft te maken met hoevaak de cpu de data die hij nu nodig heeft in de l1 cache kan vinden.
hoe hoger de hitrate hoe beter want dat betekend minder vertraging.
AMD kan er meer data in stoppen en dus zo zijn kansen vergroten, en intel kan vaker en sneller de data in de l1 wisselen om zo een evergrote hitrate te hebben.

ik hoop dat dat iets duidelijker is.

[Verwijderd]

Sorry, maar dat is niet helemaal waar.

Als iets gecachet wordt, wordt de plek in de cache bepaald door de laagste bits. Hierdoor is het mogelijk dat twee adressen verwijzen naar dezelfde plek in de cache. De associativiteit bepaalt het aantal niveaus in de cache wat bekeken wordt om te bepalen of er een cache-hit is. Een lagere associativiteit betekent dus een snellere cache-lookup, maar ook een grotere kans op evictie (data in de cache die vervangen wordt door andere). Er zal dus sprake zijn van een optimum associativieit, dit verschilt per processor.

[Verwijderd]

Vermits google sneller is dan het terug opzoeken in een cursus van tijdens studies:

http://www.pcguide.com/ref/mbsys/cache/funcMapping-c.html

Of vertaald: elk stuk cache geheugen wordt toebedeeld aan een bepaald stuk RAM. Bij Core wordt een groot stuk cache toegewezen aan een groot stuk RAM, bij K8 meer kleinere stukken cache aan kleinere stukken RAM. Vermits een proces als het loopt meestal data gebruikt uit één stuk RAM, zal de k8 sneller zaken moeten overschrijven in zijn (kleine) cache dat is toegewezen voor dat specifieke (kleine) stuk RAM.

Waarom gebruikt K8 dan ook geen 8-way associative: de decoding logica om uit te maken of (en waar) de gezochte data in het groot stuk cache (relatief, want bij 8 is het dus 8 lijnen) is complex, en neemt dus ook plaats in op de chip (en kost tijd). Zoals altijd... flexibiliteit (hier: elk stuk cache geheugen kan voor eender wat gebruikt worden) geeft complexiteit!

[Kaaswagen]

Misschien nog een pikant detail: De Core zou perhaps passief zijn werk kunnen doen, een niet te onderschatten voordeel. Het is natuurlijk niet zo dat dat ook maar enigzins met prestaties van de architectuur te maken heeft, maar het speelt zeker mee.

[TheSiemNL]

Je kunt zoveel passief doen maar dan moet je wel airflow in je kast hebben. En wat gebruik je voor airflow? Juist koelers. Intel is goed in het verleggen van problemen.

[gamepower2005]

Natuurlijk heb je koelers in je kast nodig. Het punt is dat er nu geen enkele state-of-the-art processor is die zonder een speciale koeling kan blijven werken. Conroe zet tegelijkertijd fantastische benchmarks neer EN doet dit passief gekoeld.

[poepkop]

Een venice kan ook passief gekoeld worden, mijn vader heeft een 3200+ met Zalman koeler en dmv Qfan draait die fan niet tot nauwelijks met de cpu op 2,5ghz...

[Countess]

ik heb alleen nog de lager geklokte conroe's passief gekoeld gezien
en dat kunnen de low voltage modelen van AMD ook met gemak(zowel de 25 als de 35 watt modelen), en als AMD overschakkeld op 65nm waarschijnlijk nog makelijker.

[Countess]

tja niet heel gek dat er nogal wat verschil zit in de k8 en de core.
de k8 is al aardig wat jaartjes op de markt en de core nog helemaal niet.

en een aantal dingen in core komt er gewoon op neer van "meer en groter" iets wat AMD ook vrij makelijk zou moeten kunnen doen.

[TheCapK]

Toch zou AMD een aantal van deze verschillen waarschijnlijk tijdens het fabricage proces al gelijk kunnen trekken en zo al de verschillen met de Conroe kleiner maken. Als ze dit niet doen betekent dit dat ze waarschijnlijk al iets anders in gedachten hebben wat beter is!

[Verwijderd]

In de K8L, die waarschijnlijk dit jaar nog op de markt wordt gezet, is het aantal FPU's waarschijnlijk 2 keer zo groot en er worden nog een aantal andere verbeteringen doorgevoerd.
Maar alleen die FPU's zouden moeten zorgen voor 50% performance winst in FP-intensieve software, en daarmee komt de performance weer zo'n 10-20% boven die van de Conroe (die nu zo'n 20% boven de K8 zit).

[pietje63]

Tja, wat zeggen al deze theoretische dingen nu echt? Eerst was het altijd 'zoveel mogelijk ghz' nu misschien 'zoveel mogelijk dit en dat' en over een paar jaar 'zoveer mogelijk cores'. Waar het echt om draait is de snelheid in de praktijk.. en die is weer wisselend per doel enzo.

[Countess]

tja is toch met alles zo?
eerst moeten autos alleen maar veel paarde kracht hebben,
toen moesten ze ook goede wegligging hebben, en later moesten ze ook nog veilig zijn en nu moeten ze ook nog zuinig zijn.

[RetepV]

Nou maar wachten op de bugs in de Intel processor. Nieuwe architectuur = nieuwe kinderziektes. De K8 architectuur bestaat al een tijdje, daar zijn de meeste kinderziektes wel uit.

Als je een datacenter runt, neem je dan het risico van data corruption door een ontwerpfoutje van de processor? Het is al eerder gebeurd...

[Verwijderd]

Dit is al eerder gebeurt aan beide kanten (Intel en AMD).

AMD is de laatste geweest dus zeg het maar, wat moet je als je een datacenter runt?

Power/Sun/Risc/alpha?
Die elk ook wel een foute serie hebben gehad denk ik.

[packman]

Een van de grote sterktes van de K8 architectuur is en blijft Hypertransport... Multi-core en multi-processor systemen gaan een steeds belangrijkere rol spelen in de toekomst, langzaamaan wordt die trend al gezet. Heeft Intel hier iets aan veranderd aan zijn "shared bus" principe uit de oertijd?

Voor desktop gebruik zal Intel hier wel even de beste CPU's hebben als er processors met deze Core architectuur beschikbaar worden, maar voor server-omgevingen zie ik dit dan toch niet meteen gebeuren dat de opmars van AMD gestopt wordt als ze nog steeds aan dat shared bus principe blijven vasthouden...

[Wouter Tinus]

HyperTransport doet helemaal niets voor multicore; het verzorgt alleen communicatie tussen processors onderling. Core heeft met zijn gedeelde L2-cache en directe verbinding tussen de twee L1-caches een duidelijk verdere integratie dan de K8.

Van een gedeelde bus is in het Bensley-platform ook geen sprake meer: iedere processor krijgt zijn eigen bus. Later zal dit ook voor de Xeon MP worden ingevoerd. Het is nog net geen HyperTransport maar het neemt wel een aantal bottlenecks weg.

Overigens is juist HyperTransport een van redenen waarom Opteron-servers erg moeilijk op te schalen zijn boven de vier sockets, want de hoeveelheid bandbreedte die nodig is om de caches synchroon te houden stijgt dan (veel) sneller dan die van het FSB-systeem. AMD werkt aan oplossingen hiervoor, maar Intel kan natuurlijk soortgelijke trucs in zijn chipsets toepassen (zoals IBM met de X3 bewezen heeft).

[Vastloper]

"Overigens is juist HyperTransport een van redenen waarom Opteron-servers erg moeilijk op te schalen zijn boven de vier sockets, want de hoeveelheid bandbreedte die nodig is om de caches synchroon te houden stijgt dan (veel) sneller dan die van het FSB-systeem."

Je vergeet wel dat de totale bandbreedte ook opschaalt met met het aantal CPU's! Dat is met een gedeelde bus helemaal niet zo! Die blijft constant ongeacht het aantal processors (Ook bensley heeft een vaste bandbreedte). Als we het hebben over opschalen qua sockets op een moederbord dan is Intel echt in het nadeel.

Ander punt is dat ook de geheugenbandbreedte niet gedeeld hoeft te worden bij AMD en dat als software genoeg geparalelliseerd word en er goed gebruik word gemaakt van lokaliseringen dat AMD dan zeker een groot voordeel blijft houden wat betreft schaalbaarheid, omdat cache coherency dan niet zoveel meer van belang is (aangezien een eigen geheugenbank genoeg is voor de meeste thread's of paralelle programadelen).

2 FSB's aanbrengen vanuit de chipset is nog steeds iets heel anders dan meerdere cpu's die direct met elkaar praten en hun eigen geheugen hebben!

[Wouter Tinus]

Je vergeet wel dat de totale bandbreedte ook opschaalt met met het aantal CPU's! Dat is met een gedeelde bus helemaal niet zo!

Ook met een bussysteem kun je gewoon extra geheugencontrollers toevoegen. De Intel E8500- en IBM X3-chipsets ondersteunen bijvoorbeeld beide vier dualchannel DDR2-controllers voor vier processors. Bensley zal vier kanalen voor twee sockets ondersteunen. Beide doen dus niet onder voor de hoeveelheid bandbreedte die Opterons tot hun beschikking hebben.

Ander punt is dat ook de geheugenbandbreedte niet gedeeld hoeft te worden bij AMD en dat als software genoeg geparalelliseerd word en er goed gebruik word gemaakt van lokaliseringen dat AMD dan zeker een groot voordeel blijft houden wat betreft schaalbaarheid, omdat cache coherency dan niet zoveel meer van belang is (aangezien een eigen geheugenbank genoeg is voor de meeste thread's of paralelle programadelen).

Lokaal geheugen heeft een lagere latency maar het zorgt er echt niet voor dat de cache coherency genegeerd wordt. Wat als een andere CPU stiekem iets veranderd heeft in jouw stukje geheugen? Dat moet en zal altijd gecontroleerd worden.

2 FSB's aanbrengen vanuit de chipset is nog steeds iets heel anders dan meerdere cpu's die direct met elkaar praten en hun eigen geheugen hebben!

Dat beweert ook niemand, maar een dedicated FSB is lang niet zo inferieur zal sommige mensen lijken te denken. Er blijven nadelen qua latency maar het is niet alsof dat dodelijk is, zeker niet met de enorme caches die Intel kan en zal gebruiken.

[Verwijderd]

Dat beweert ook niemand, maar een dedicated FSB is lang niet zo inferieur zal sommige mensen lijken te denken.

Gezien de oplossingen die beschikbaar zijn is een dedicated FSB wel degelijk inferieur. HyperTransport is gewoon een veel betere oplossing. De Opteron systemen hebben dat keer op keer bewezen. Daarnaast neemt HyperTransport 3.0 de boel mee naar een hoger niveau. Daar kan geen shared/dedicated of wat voor andere FSB dan ook aan tippen. Er zijn te veel toeters en bellen nodig om een "ouderwetse" FSB enigszins efficient te maken. Dat kost geld en snelheid. Waarom denk je dat intel van grote L2 Caches houdt? Doen ze niet voor de lol hoor. Bij Quad Core chips zal het nog erger worden. 8MB L2 zal dan "minimaal" zijn.

HyperTransport is flexibel en je hoeft niet alle data over 1 en dezelfde FSB te laten lopen. Bij 4-way Quad Core systeem zul je veel beter de kracht van HyperTransport zien.

[Vastloper]

Lokaal geheugen heeft een lagere latency maar het zorgt er echt niet voor dat de cache coherency genegeerd wordt. Wat als een andere CPU stiekem iets veranderd heeft in jouw stukje geheugen? Dat moet en zal altijd gecontroleerd worden.

Dit bedoel ik dus met software genoeg geparalleliseerd maken. Ik kan je voorbeelden van software geven waarbij dit dus nooit gebeurt. Als je programeeromgevingen gebruikt die gemaakt zijn voor parallel programming, dan heb je die problemen niet. Omgevingen zoals MPI waarbij alle communicatie tussen processoren expliciet is. Dan laat je het wel uit je hoofd om onnodig elkaars geheugen te gebruiken. Dit heeft naar mijn idee toch ook de toekomst met alle multi-cores die eraan gaan komen.

Het punt is ook dat AMD bezig is met software die applicaties automatisch omzet voor gebruik van meerdere core's, dit heeft zeker wel veel potentie op hun eigen platform, mits de implementatie natuurlijk degelijk is.

Ander voordeel is ook de single chip chipset en de eenvoudigere chipsets. Chipsets hebben veel minder pinnen en pcb sporen nodig dan wanneer er voor elke CPU weer een aparte FSB gemaakt moet worden, zoals in bensley dan.

Intel heeft gewoon een inferieur systeem wat betreft FSB en het word tijd dat ze hier wat aan gaan doen naar mijn idee.

[EaS]

Yep, HyperTransport is helemaal geen elegante oplossing. We houden het gewoon bij de prachtige FSB techniek waarover we gewoon alle inter-processor communicatie, cache coherency traffic en memory access gooien. Lopen we tegen problemen aan? Gooien we toch even wat silicon tegen een snoop filtertje aan? Nog niet genoeg? Proppen we toch gewoon wat extra FSB paadjes in de northbridge. Nog steeds niet genoeg? Hup, een extra vierkante kilometer aan cache.
Hypertransport is in technisch opzicht al bijna aan z'n 5de verjaardag toe, en Intel is nu nog bezig om met allerlei foefjes dezelfde schaalbaarheid uit z'n platform te toveren. Terwijl de volgende generatie HT niet eens meer zo lang op zich laat wachten.
Andere leuke dingen die HT biedt als co-processor uitbreidingen zijn ook niet mogelijk op Intel's "future" platform.

Let wel: Ik zeg niet dat Intel geen gelijkwaardige (of zelfs betere) performance uit z'n aankomende platform kan toveren, maar het blijven maar uitbreidingen bovenop uitbreidingen. Die alleen nodig zijn vanwege AMD's elegante Hypertransport.
Nee, ben zeer benieuwd naar CSI.

[Verwijderd]

leuk dit verhaal!

ik krijg na het lezen van dit verhaal een beetje het idee dat de core architectuur niet veel van die van de k8 verschilt... met uitzondering van het feit dat intel overal +1 of +2 heeft toegepast... geen wonder dat dit dan sneller zal zijn... helemaal als je bedenkt dat de k8 al een oudje is...

hopen dat amd dit truucje ook uit kan halen.. wanneer zij ook een shrink uit voeren naar 65nm hebben ze toch mooi 38% meer ruimte om, ook wat meer cache etc toe te voegen!

zou mooi zijn, want het beeld dat nu geschetst wordt ziet er niet best uit voor AMD en zijn ze al hun zuur verdiende marktaandeel zo weer kwijt...

[smokalot]

Wat ik niet zo goed snap is wat de kosten zijn van al die betere dingen van de core tov K8, het lijkt me dat veel dingen een trade-off zijn toch? Op zijn minst in die-grootte?

Een DAF vrachtwagen heeft ook meer vermogen dan een ferrari...

[John_Glenn]

Niet echt een goed vergelijking... een DAF en een Ferrari moeten zichzelf voorttrekken. Deze dingen hoeven alleen maar data te sleuren, dus hebben niet zo'n last van hun eigen grootte

Meer execution units zorgt inderdaad voor een grotere die, maar Intel produceert intussen al op 65nm, tegen AMDs 90nm, dus dat maakt het probleem kleiner.

[Verwijderd]

Deze dingen hoeven alleen maar data te sleuren, dus hebben niet zo'n last van hun eigen grootte

Zoals ik hierboven al aangaf, op zo'n korte tijd als één klokcyclus spelen de afstanden die moeten afgelegd worden wel degelijk een rol! In de p4 bv zijn er klokcycli 'voorzien' om een signaal van de ene kant van de chip naar de andere te verplaatsen (de die was te groot vergeleken met de kloksnelheid).

[Countess]

het voornaamste is idd die grote, en complexer betekend ook meer kans op fouten (zowel in ontwerp als bij de productie wat effect heeft op de yields)

maar zodra er een verkleind productie process is geintroduceerd dan kan de complexitijd van de CPU's omhoog omdat ze dan de productie op pijl kunnen houden zelfs met de verhoogde complexiteid.
daarom zie je bv ook geen dual cores voor het 90nm process er was el zullen we waarschijnlijk ook geen quad cores zien op 90nm maar alleen op 65nm.