Details toekomstige AMD-processors onthuld

Tijdens een gastcollege op de technische universiteit van Michigan over de toekomst van chipproductie heeft processorarchitect Jerry Moench een aantal onthullende opmerkingen gemaakt over de 90nm-versie van K8 en K9. Moench bekleedt een hoge functie bij AMD en houdt zich op dit moment bezig met het ontwerpen van de volgende generatie chips. Op de discussieforums van Ace's Hardware en Real World Technologies is men al druk aan het praten over de videobeelden, waarin een tweetal nieuwe stukken informatie gevonden zijn.

Het eerste gaat over de 90nm-versie van K8, waarvoor AMD de snelheid van het L2-cache heeft verlaagd. In plaats van direct met de core mee te rennen (full-speed) gaat het op minder dan de helft van processorklok draaien, iets wat logischerwijs een negatief effect heeft op de L2-bandbreedte en -latency. Ook de geïntegreerde northbridge wordt langzamer gemaakt; deze gaat op de helft van de processorklok draaien. Hoewel AMD dankzij een groot L1-cache en lage geheugenlatency minder profiteert van het L2-cache dan de Intel Pentium 4, doen deze feiten toch vermoeden dat de 90nm-versies op gelijke kloksnelheid minder goed zullen presteren dan de huidige Athlon 64-modellen. Het is niet duidelijk waarom deze beslissingen zijn genomen, maar gezien de context van de presentatie is het waarschijnlijk gedaan om betere yields te halen en zuiniger te zijn op 0,09 micron.

Een ander opmerkelijk feit is dat de K9 net als de Pentium 4 ontworpen wordt met een trace cache. Dat wil zeggen dat instructies zodra ze vertaald zijn naar interne micro-ops worden opgeslagen, zodat in het geval van een branch misprediction de decodeerstappen van de pipeline niet opnieuw doorlopen hoeven worden. Hiermee wordt het kritieke pad - het stuk dat wél opnieuw gedaan moet worden als de branch predictor de fout in gaat - verkort, in het geval van de Pentium 4 met ongeveer 30%. Omdat nog niet bekend is hoe lang de pipeline van K9 in totaal is, kan ook nog niet gezegd worden of de nieuwe generatie daadwerkelijk een korter kritiek pad zal hebben dan K8.

Reacties (40)

[Verwijderd]

Een ander opmerkelijk feit is dat de K9 net als de Pentium 4 ontworpen wordt met een trace cache. Dat wil zeggen dat instructies zodra ze vertaald zijn naar interne micro-ops worden opgeslagen, zodat in het geval van een branch misprediction de decodeerstappen van de pipeline niet opnieuw doorlopen hoeven worden.

deze uitleg van trace cache komt niet overeen met het model dat ik van trace cache heb. trace cache bevat idd de vertaalde x86 CISC instructies naar "uops", de RISC achtige instructies waar de execution units intern mee werken.

voordeel is dat als dezelfde x86 code opnieuw uitgevoerd moet worden, bijvoorbeeld in een lus, de vertaling van x86 naar uops achterwege gelaten kan worden; de uops bevinden zich immers al in de tracecache. het is zo een uiterst effectieve code cache voor het schizofrene x86 CISC/RISC processingmodel.

ik zie branchprediction als onafhankelijk van de tracecache en begrijp de prominente rol van branchprediction in de beschrijving van tracecache in het artikel niet zo goed. helemaal het voordeel dat een tracecache zou geven aan een branchmisprediction zie ik niet.

overigens is tracecache een patent van intel meen ik, zou amd en intel amd64 en tracecache hebben uitgeruild?

edit:
@tigeris

ah ok een tracecache bevat dus de "segmentjes code". deze segmentjes komen overeen met code tussen branches in het werkgeheugen dat recent uitgevoerd is. bij elke branch in de code begint en eindigt een nieuw segmentje aka trace, vandaar de naam tracecache. traces zijn in dit opzicht een soort macros die opgeslagen worden in de tracecache en razendsnel opnieuw afgespeeld kunnen worden zonder cacheline boundary problemen of bandwidth problemen van het memory subsystem.

het extra aspect wat intel er bovenop gooit is het opslaan van micro ops ipv van x86 cisc instructies. hierdoor wordt de x86 cisc decoding slag uitgespaard. maar goed kan goed zijn dat intel dit extra aspect niet gepatendeerd heeft hoor, stond me iets van bij.

[Verwijderd]

overigens is tracecache een patent van intel meen ik, zou amd en intel amd64 en tracecache hebben uitgeruild?

Net als bij alles gaat het om de implementatie, een bepaald techniek kan op verschillende wijze geimplementeerd worden. En omdat de P4 en Athlon 64 totaal verschillend van elkaar zijn is het volkomen logisch dat AMD's implementatie anders is dan die van intel, hoewel ze uiteindelijk het zelfde resultaat moeten geven, nl het verlagen van de latency.

Intel heeft patent op hun implementatie van de trace cache, de trace cache is geen uitvinding van intel hoor ! Intel is wel de eerste die het in een x86 processor gebruikt.

Lees hier meer over de Trace Cache, en de bedenkers.

[Verwijderd]

Deze actie heeft twee voordelen die te maken hebben met schaalbaarheid :

- Door de cache-snelheid te halveren neemt het stroomverbruik enorm af, wat o.a. gunstig is voor warmte; en stroomlekkage, wat een groter probleem is op 90nm.

- Door de cache-snelheid te halveren kan men de cpu-frequentie weer een behoorlijk stuk laten stijgen, de cache-frequentie is geen belemmering meer.

Een oude truc uit de trucendoos toen de Mhz ook erg aan het stijgen was.

[Madrox]

dus zoals je zelf al aangeeft is het een kwestie van balans in de architectuur; want het voordeel dat ze behalen met het halveren van de cache raken ze weer kwijt aan het versnellen van de core. Blijkbaar is er meer behoefte aan een hogere klok dan aan het behouden van de cache-speed.

[Verwijderd]

Als de core te weinig gebruik maakt van het feit dat de cache op 100 procent draait. Laten we zeggen dat de core gemiddeld 3 cycles bezig is voor ze het cache aanspreekt, kan een verlaging gunstig zijn.

Dat is inderdaad een balans, die per architectuur anders is.

[gp500]

zoiets denk ik wel jah, maar ik twijfel of het zo'n hele grote stap wordt.

P3 vs p4, denk dat amd het niet zo drastisch doet.
't zal er ook wel mee te maken hebben dat ze dan de sse > 2/3 sneller kunnen laten gaan werken.
terwijl de FPU gelijk blijft, en dus niet echt afzakt zoals bij de p4 toen.

[TIGER79]

hhhmmmm....
klinkt bij mij allemaal niet zo positief... lijkt wel dat ze weer een stap terug doen in de tijd aaangezien oudere cpu's (volgens mij waren dat de oudere pentium 4's correct me if i'm worng) die hadden ook maar gehalveerde cachesnelheid...
ik hoop alleen dat ze snel genoeg blijven om te concurreren met Intel want dat blijft de voordeligste situatie voor ons consumenten

[Countess]

de k6 en k5 hadden vroeger ook een cache die half zo langzaam liep.
die waren ook niet vooruit te branden.

maar gezien het verschil in prestaties tussen de 3000+ (2ghz 512kb cache en de 3200+ (2ghz 1mb cache) lijkt me l2 cache niet echt belangrijkt voor de k8.
en die tracecache lijkt me ook best interestant eigenlijk. AMD heeft al minder branchmis-predictions als intel (omdat het makelijker voorspellen is met korte pipelines) en nu krijgen ze ook nog minder snelheids verlies als het dan toch een keer gebeurt.

[mr._Anderson]

maar gezien het verschil in prestaties tussen de 3000+ (2ghz 512kb cache en de 3200+ (2ghz 1mb cache) lijkt me l2 cache niet echt belangrijkt voor de k8.

Hier maak je een vergelijking tussen l2 cache groottes die nog op full speed allebei draaien. de grootte is inderdaad wat minder belangrijk bij K8.

Echter in dit artikel gaat het over de snelheid van de l2 cache, dat kan wel degelijk een grotere impact hebben.

[familyman]

De grootte bij 32bit operatie is niet zo heel belangrijk. Mijn gevoel zegt me dat het bij 64bits operatie wel belangrijk is. (of belangrijker wordt)

[Mentalist]

de k6 en k5 hadden vroeger ook een cache die half zo langzaam liep.
die waren ook niet vooruit te branden.

U gaat jammer genoeg ook niet door voor de koelkast . De K5 en K6 hadden helemaal geen L2 cache, dat zat usually op het moederbord en liep op FSB snelheid. De K6-3 kreeg pas L2 cache mee, 256KB fullspeed. Als je zo'n CPU op een mobo plaatste die zelf al L2 cache had werd de cache op het mobo dus L3 cache.

[Croga]

AMD heeft al minder branchmis-predictions als intel (omdat het makelijker voorspellen is met korte pipelines)

Om precies te zijn hebben ze net zoveel mispredictions, maar hoeft er minder weg gegooid te worden (de pipeline) dan bij een P4. Een prediction-miss zal dus minder negatieve invloed op de performance hebben....

[florizla]

Hoe weet jij dat ze evenveel mispredictions hebben? Ze gebruiken echt niet dezelfde prediction-architectuur dus er zal wel een klein verschil opzitten!

[Wouter Tinus]

de k6 en k5 hadden vroeger ook een cache die half zo langzaam liep.
die waren ook niet vooruit te branden.

Ook de eerste versies van de Athlon hadden een extern L2-cache op 50% van de coresnelheid, later werd dat zelfs nog verlaagd naar 40% en uiteindelijk 33% omdat ze die cachechips niet snel genoeg konden krijgen tijdens de race naar 1GHz. Pas toen ze overstapten op de Thunderbird-core (Socket A) kwam het L2-cache full-speed on-die te zitten.

[Verwijderd]

In principe is het wel positief. Ook al gaat de L2 latency omhoog doordat de snelheid omlaag gaat, hierdoor wordt hij namelijk wel veel zuiniger (als hun verhaal klopt). Zuiniger wil zeggen, minder lekstroom en dus minder warmte. Minder warmte kan dan weer vertaald worden naar een hogere kloksnelheid die uiteindelijk het verlies door de halvering gedeeltelijk goed zou kunnen maken.

Kijk naar de huidige run op Barton-M's dit vanwege de lagere warmte productie. Ik denk dat dit zeer zeker een goede stap is. De processorfabrikanten zien nu in dat ze nu eerst eens moeten zorgen voor een degelijke (qua warmte) en dus koude cpu en kunnen dan weer de snelheden gaan verhogen. Nu wordt er dus in mijn ogen een marge gemaakt zodat ze daarna weer hogere kloksnelheden kunnen halen. En in the end zal dat allemaal weer goed zijn.

* 786562 thekip

[TheBorg]

Volgensmij waren dat de eerste generaties Celerons. Maargoed, zo te zien hebben zowel AMD als Intel grote problemen met het 0,09 micron procede.

[EXX]

Helaas, u gaat niet door voor de koelkast....

De Pentium II en de eerste versie van de Pentium III (Katmai) hadden een externe L2 cache die op de halve snelheid liep. Bij de Celerons zat de cache altijd al on-chip en liep op volle CPU snelheid (afgezien van de allereeste Celerons met Covington core, die had helemaal geen L2 cache). Ondanks dat de Mendochino Celerons dus maar 1/4 vd cache ter beschikking hadden tov de Pentium II en de Katmai Pentium III, waren ze op gelijke clock bijna net zo snel. Conclusie: veel cache is goed, snelle cache is beter.

[jp]

Inkoppertje: En veel snelle cache is best

[Puppetmaster]

weet iemand eigenlijk waar de K's van de AMD processornamen vandaan komen?

[EaS]

weet iemand eigenlijk waar de K's van de AMD processornamen vandaan komen?

De K die voor het "familienummer" staat, staat voor Kryptonite. Kryptonite is dat goedje dat Superman z'n krachten deed ontnemen, en hem op z'n knieën deed dwingen.
Superman staat natuurlijk in deze vergelijking voor Intel.

[familyman]

Gezien de populariteit van de AMD64's wordt het dan ongeveer nu tijd voor een nieuwe letter.

Misschien de S van Spinach

Als in het groene goedje dat een bepaalde matroos gebruikte om zo sterk te worden dat een bepaalde grote lomperik mee om de oren te slaan. (vul de bedrijfsnamen zelf maar in)

De frêle dame waarom gestreden wordt, en de opvolger van Loïs Lane, zou prima kunnen staan voor de argeloze consument in het midden van deze titanenstrijd.

Andere suggesties?

[Dual Infinity]

Heuh.. was het niet zo dat Superman juist zijn kracht kreeg van het Kryptonite, en dat op het moment dat dat verwijderd werd z'n krachten ook pleite waren?
Gezien ie van planeet Krypton kwam, lijkt me dit ook logischer..

[Deadsy]

juist niet kryptonite schaad superman juist
er zijn meerdere soorten maar ze hebben allemaal een slecht effect op hem.

het (op de meeste plekken) afwezig zijn van kryptonite op de aarde maakt het juist mogelijk dat hij sterk is en vliegt.

dus wat -EAS- zegt klopt.
het spul heet kryptonite omdat het ik dacht van het centrum van de planeet komt

[phreako]

Dacht dat ze ze hadden vernoemd naar bekende paarden.

[Verwijderd]

Thunderbirds TV series

[Verwijderd]

ik denk dat dit een goede stap is om het vermogen terug te dringen, prestatie is natuurlijk leuk en zelfs belangrijk maar teveel stroom vreten levert veel hitte op... ik denk dat Intel hier ook niet aan ontkomt als je het vermogen verbruik van de prescot bekijkt

[Twarp]

Al vind ik het bij de Prescott best meevallen hoor, iedereen loopt maar te roepen dat dat ding zo warm wordt, maar ik heb er geen last van, mijn Northwood wordt warmer zelfs.

De schaalbaarheid van de CPU zal een stuk beter worden denk ik, gelukkig heeft AMD een stevige L1 cache waarmee ze een groot voordeel hebben op iNTEL. Mijn vermoeden is dat op het moment dat de CPU op de markt komt het best nog wel eens mee kan vallen, we moeten alleen even wachten nog....

[Rey Nemaattori]

Het zou pas echt leuk worden als dmv het verven van bruggen je de cachesnelheid kunt instellen.(een divider oid)

[Verwijderd]

Wat is nou precies het voordeel van 0,09 micron t.o.v. de 'oude' 0,13 micron? Is het alleen maar, om te laten zien hoe klein ze processoren kunnen maken, of geeft het op lange termijn wél een echte prestatie winst...

[Countess]

het gaat erom meer CPU's uit 1 waffer te kunnen krijgen.
kan je er namelijk sneller meer maken EN zullen ze goedkoper zijn

en tot aan de 0.13micron werden de CPU's na elke verkleining ook zuiniger (de hoeveelheid stroom die ze nodig hebben om hun werk te doen word minder)
maar de lekstroom (stroom die uit de transistors lekt als ze op "uit" staan) werd elke keer groter, exponentieel groter zelfs bij elke stap. bij intels 90mn process heeft de lekstroom toename duidelijk het verminderen van het stroom verbruik overstroffen.
omdat AMD SOI (silisium on insulator) gebruik kan de stroom minder makelijk uit de CPU's lekken en zou de lekstroom dus minder moeten zijn waardoor AMD's stroom verbruik minder groeid, of misschien zelfs wel wat minder word met het overstappen op 90mn.

nog een voordeel is dat ze vaak wat makelijker hoger te clocken zijn ,en de yields (uitgedrukt in hoeveelheid gelukte cpu's per waffer) sneller better worden.
al zal de yield percentuweel gezien nog wel even achter lopen... maarja met 90mn kan je ook meer als 2 keer zoveel cpu's uit een waffer halen als met 130mn, dus dat is niet zo erg

[Wouter Tinus]

Een belangrijk voordeel voor AMD is dat kleinere processors goedkoper zijn. De Athlon 64 is een vrij grote chip en AMD heeft maar één fabriek die ook nog eens 200mm-wafers gebruikt in plaats van de veel grotere 300mm-wafers van Intel. Een ander punt is de kloksnelheid, die zou met 0,09 micron-technologie flink omhoog moeten kunnen. Intel en IBM slagen daar tot nu toe niet echt in, dus wellicht hoopt AMD door deze consessies te doen betere resultaten te halen.

[Olaf van der Spek]

Er passen meer chips op een wafer, dus in theorie kunnen de chips goedkoper en sneller worden gemaakt.

[T-MOB]

kortere banen dus een potentieel hogere kloksnelheid, lagere spanning mogelijk dus energiezuiniger en minder warmte-afgifte.
Daarnaast kunnen er meer chips op één wafer dus efficiënter te produceren: goedkoper en beter voor het milieu.

[Ranime562]

Ik geloof dat het ook iets te maken heeft met minder gebruik van energie.

De chips zouden in theorie, hogere snelheden kunnen halen, op lager voltage en minder warmte produceren.

Tenminste, dat is de kern gedachte er achter.

misschien vanuit commerciëel oogpunt... maar dat weet ik niet zeker, kunnen er meer procs per wafer worden geproduceert?

[Madrox]

het verkleinen van de core (bijv. door middel van kleinere micron) heeft meerdere voordelen zoals meer transistors kwijt kunnen op hetzelfde (of kleiner!) oppervlak, kortere lijnen wat positieve invloed heeft op stroomverbruik en goedkopere produktie omdat ze uit dezelfde maat wafel meer dye's kunnen halen.

Hitteafvoer word daarentegen weer kritischer, want als het oppervlak kleiner word is het lastiger die hitte efficient af t e voeren.

[pietje63]

Volgens blijft de snelheid van de cache gewoon gelijk gaat alleen die van de rest van de cpu heel erg omhoog .

AMD zit nu rond de 2GHZ, dat blijft de snelheid van de cache, en dan wordt de cpu meer dan 2x zo snel, een dikke 4 GHZ dus.

* 786562 tommy84

[Metal Baron]

Dat is dus niet waar, je CPU wordt pas 2 x zo snel als alles 2x zo snel wordt, je cache dus ook

[C00P]

Vraag me af : Is een gelijkgeklokte 90 Nano dan iets langzamer dan zijn 130 nano broertje ?
Is er ook aan de pipeline gekomen, of is dat de enige verandering ?

[familyman]

Misschien iets minder latency, dwz vertraging tussen het uitvoeren van deelstapjes. Lijkt me overigens een onmeetbaar voordeel.

Maar voor de rest moet er echt iets met frequenties en ontwerpen gebeuren hoor! 90nm biedt hiervoor alleen meer mogelijkheden en daarom is het belangrijk.

[Chello200]

Is het mogelijk om met een pencil of wire trick de cache op full speed te laten lopen als je het zelf wilt tweaken ?