Paul DeMone over de P4 Cache Architectuur

De welbekende Paul DeMone heeft ons weer weten te verblijden met een stukje over de Pentium4. Deze keer met name over de cache architectuur...

Big Willy’s Little Cache

Almost lost among the marketing platitudes of IDF were a few interesting new facts about Willamette. When Intel conceived the new core, they apparently decided that data memory access latency was enemy number one. The centerpiece of their attack on latency is their controversial decision to use a smaller data cache, 8 KB, than in their last four releases of P6 based processors. This also stands in stark contrast to the 64 KB data cache in arch competitor AMD’s K7 Athlon processor line. It is well known that the larger a cache is the greater chance it contains the data item the CPU needs next. As a useful rule of thumb, quadrupling the size of a cache cuts its miss rate in half.

Associativity indicates the number of places in a cache that any particular piece of data could be placed. The more places a data item can go, the less chance that several frequently used pieces of data will fight over the same place(s) in the cache and keep knocking each other out, forcing so-called conflict misses. Associativity also happens to be more effective in reducing the miss rate of small caches than large ones.

Although the Willamette data cache is 1/8th the size of the AMD K7’s data cache, it is more highly associative: 4-way versus 2-way. As a result of these two factors, the miss rate of Willy’s little data cache is only about 2.2 times higher than the much larger data cache in the K7 for most programs run on a PC.

With all this extra area, and more transistors (42 million versus 28 million for coppermine) why not put in a 32, 64, or even 128 KB data cache? The only reason that makes sense is the war on data access latency. Because they wanted their data cache to operate with a 2 cycle latency, Intel could not make it larger than 8 KB in size in their 0.18 um process without placing it on the critical timing path, and thus limiting the processor clock rate (demonstration systems at IDF ran at up to 2 GHz). Larger memory arrays require longer access time, and as a result the larger data cache in the K7 Athlon has a latency of 3 clock cycles.

Al met al een heel interessant artikel waar je wel even zoet mee kunt zijn en een hoop van kunt opsteken. dEjAvU tipte ons alweer.

Reacties (19)

[Verwijderd]

Wacht ff... Dus ze maken minder cache (trager) zodat-ie op hogere clockspeeds (sneller) kan lopen...

Is dat

a) per saldo toch sneller
b) niet sneller, maar simpelweg een truuk om te kunnen blaten dat je een 2GHz proc hebt terwijl de concurrent het "maar" met 1.5GHz moet doen?

[JeroenB]

Cache is er om veelgebruikte data dichtbij de CPU te trekken ipv dat het allemaal steeds uit het geheugen moet komen.

De cache is ingedeeld in een aantal "lines" waar de meestgebruikte data (als je ergens een byte vandaan leest, dan wordt een stukje geheugen erachter ook meteen in de cache gezet) terecht komt. De plaats in de cache is gerelateerd aan de plaats in het daadwerkelijke geheugen, zodat de CPU aan een adres (dat dus naar een plek in het geheugen wijst) kan zien waar hij in de cache moet zoeken. De associativiteit van een cache geeft aan hoeveel verschillende lines er tegelijk in de cache terecht kunnen komen die in hetzelfde gebied liggen.

In de praktijk is de associativity belangrijker als je vaak kris-kras door het geheugen springt. Een grotere cache is zinniger als je veelal lineair door grote stukken geheugen fietst.

een kleinere, 4-way associative cache lijkt mij beter, omdat juist de "kris-kras" read/writes de momenten zijn dat de performance het meest onder druk staat.

[martdj]

Er wordt door de meesten over het hoofd gezien dat Intel ook de weg had kunnen kiezen van AMD en voor een grotere cache met een hogere latency (3 cycli) (en een grotere die) had kunnen kiezen en dan ook hoge kloksnelheden had kunnen halen. De afweging is dus geweest: 1œ keer zo lage latency, kleinere die-size, 2,2x zoveel kans op een cache-miss of gewoon AMD volgen en ze hebben bedacht dat die kleinere latency (en kleinere die-size) belangrijker waren dan de grotere kans op een cache-miss. Dat zullen ze niet zomaar gedaan hebben. Die lagere latency kan dus best weleens belangrijk zijn en heel goed uit blijken te pakken. De grote vraag is natuurlijk hoeveel invloed het economische punt: kleinere die-size, heeft gespeeld.

* 786562 martinus
/off-topic
Jippie, mijn 100-ste posting!!
/off-topic

[Verwijderd]

De afweging is dus geweest: 1œ keer zo lage latency, kleinere die-size, 2,2x zoveel kans op een cache-miss of gewoon AMD volgen en ze hebben bedacht dat die kleinere latency (en kleinere die-size) belangrijker waren dan de grotere kans op een cache-miss.

Dat was geen afweging maar een onderdeel van het ontwerp, en komt er nog es bij dat het een heel ander manier is dan die van AMD.
En helemaal omdat de pipeline 20 stages is.

---------------
Waarom is deze reactie overbodig... graag uitleg !!

[Pantagruel]

Uitermate leerzaam dat stukkie (inde duitse C'T staat iets soortgelijks).

Dit zou betekenen dat als Intel de P4 op 0.13 um gaat bakken er wel ruimte gaat komen voor een grotere cache zonder dat er problemen gaan ontstaan mbt timing vd datacache.

Ongetwijfeld heeft Intel voor dit moment gedacht: beter een kleinere cache die snel loopt dan een grotere cache en een "slak" van een ding

Ongetwijfeld gaan ze nu dus aan de slag om het productie proces te verbeteren en de spoorbreedte te verkleinen om zo meer ruimte te maken voor "on-die" cache. Eventjes geduld dus nog, al is het maat omdat de eerste exemplaren weinig cache hebben en schandalig duur zullen zijn.

[Delerium]

Vergeet niet dat de p4 aan het begin van een lang traject staat. De core zal nog een aantal malen worden verbeterd (net als de p6 core), dus Intel laat op deze manier makkelijk ruimte over voor verbeteringen in de toekomst.

De p4 zal in het begin volgens mij zowiezo lastig te maken zijn, dus zal men liever met weinig cache beginnen, om uitval veroorzaakt door cache te verminderen.

[Pantagruel]

Klopt helemaal.

De Pentium III van nu is uiteindelijk begonnen als PentiumPro (socket) op 66 Mhz 256/512kb cache via de MMX uitbreiding, 100 Mhz FSB met 512 kb cache @ 1/2 Core speed (SLOT-1) , 100 Mhz FSB met 256 kb cache @ Core speed (slot-1 en FC-PGA uiteindelijk bij 133 Mhz FSB en 256 kb cache @ Core speed (FC-PGA).

Eigenlijk hoort tussen de Pentium II met 512 KB op Slot-1 formaat nog de Celeron (slot-1 en FC-PGA) thuis die in weze meer op de Pentium Pro lijkt dan op de Pentium III. De 'nieuwe' celeron (pentium III afgeleide) vult het gat tussen de Pentium II en de Pentium III qua 'evolutie theorie' van de processor, niet qua de tijdslijn die Intel bedacht heeft )

[De Xeon heb ik eruit gelaten, wordt te uitgebreidt anders ;p ]

[Pantagruel]

Als reactie op Loki

het is inderdaad een hele stap terug van 64 kb cache naar slechts 8 kb. Dit lijkt dus verdacht veel op "vals spelen"om nu de snelste te zijn en met name AMD de hielen te laten zien.

De inbreuk op de overall snelheid vd P4 zal behoorlijk zijn want door de verkleinde cache hoeveelheid zal de verhouding hits/misses uit de cache flink veranderen (aantal hits neemt af). Mijn inschatting is dat dit meer negatief bijdraagd aan de snelheid dan dat de rauwe snelheids verhoging van 1/1,2 Ghz naar 2 Ghz opleverd.

Als Intel inderdaad snel naar de 0.13 um zal gaan en zo plaats en 'tijd' wint, is mijn vraag wat dan de maximale cache grote kan zijn (de CPU die wordt dan circa 38% kleiner, alleen durf ik niet te gokken hoeveel cache ruimte die zal opleveren).

Aanpassing ivm typo (128/256 kb is inderdaad 2nd level cahe, 1st level is slechts 64 kb. Met dank aan Treb.

[Treb]

het is inderdaad een hele stap terug van 128/256 kb cache naar slechts 8 kb. Dit lijkt dus verdacht veel op "vals spelen"om nu de snelste te zijn en met name AMD de hielen te laten zien.

Je haalt hier L1 en L2 cache door elkaar heen.
Het gaat hier om L1 cache.

[picobyte]

Waarschijnlijk heeft ook deze zet van intel weer meer te doen met marketing dan met processing power.
(het bekende clock voor clock syndroom)
Maar evengoed vindt ook ik het achterliggende idee niet meteen verkeerd.
Tenslotte moet je zoals Pantagruel al aangeeft gewoon de kat ff uit de boom kijken

Gepost onder het motto:
Meer cache meer ca$h

[DMT]

Intel moet gewoon oprotten met z'n cache gezeik.
Ik ben en blijf voor AMD!
Intel had nooit moeten beginnen aan die inclusive cache, dan had die cache op bijf. de Celeron II veel meer nut gehad, want nu moet er in de L2 een kopie van de L1 cache staan

Nu had C II 128 KB werd gezegd.
L1 was 32KB
L2 was 96KB

Maar 96KB was maar effectief te gebruiken, omdat bij inclusive cache een kopie van L1 in de L2 moet staan. Dat hoeft dus bij bijf de Duron van AMD niet. Die heeft 128KB L1 en 64KB L2
Maar ze hebben exclusive cache dus is het effectieve geheugen samen 192 KB. Dit omdat de L1 en L2 volop benut kunnen worden.
Dat is dus bijna 100 KB meer dan de Celeron II

Ik zou dus nooit meer gaan betalen voor een mindere proc! Ik vindt AMD gewoon the best!
Femme is nie voor nix Powered by AMD!
En dat gezeik over sommigen die denken dat de AMD minder wordt ondersteund, vindt ik ook bull omdat als dit het geval ooit zou zijn, dan is er altijd een patch.
Nou en dan ben je ook nog eens goedkoper uit en gegarandeerd van een foutloze CPU.
Want daar horen we Intel toch wel iets te vaak over toch?
En ben je dan nog nie overtuigd, dan ga je de buglistings maar eens na van AMD en INTEL .
Dat moet je toch wakker schudden.
En hoe komt het dan dat bedrijven vaak op INTEL draaien wordt dan gevraagd, nou omdat die op de holbewoners kreet 'goedkoop is duurkoop' afgaan, zonder ook maar de moeite te doen om te kijken wat nu beter is.

[Verwijderd]

euh sorry maar daar ben ik het niet mee eens.

Ik vindt het zo zielig wanneer mensen precies een kant kiezen. Intel is een fantastisch bedrijf en heeft de wereld al vaak verblijd met fantastische processor designs. Zonder intel zou AMD ook nooit zo ver gekomen zijn als het nu is.

Ik hoop juist dat Intel weer met een leuke processor komt want dat moet AMD ook weer aan het werk, krijg je nog meer concurrentie en dat betekend lagere prijzen en daar profiteren wij van.

Dat bedrijven vaak met intel in zee gaan heeft te maken met dat intel een betere reputatie heeft in de business markt. daar telt betrouwbaarheid erg en als je dan al 10 jaar met intel werkt dan blijf je daarbij. AMD begint nu pas die markt te veroveren.

Zo ik hoop dat je nu een beetje je hoofd weet te houden en dus niet weer cyberspace gaat vervuilen met je nikszeggende reactie.

btw je kan ook neit eens rekenen:
CII cache
32 L1
128L2
totaal cache: 160-32=128

Duron cache:
128L1
64 L2
totaal cache= 192K

das maar 64K meer dan de CII dus niet bijna 100, en de cache van de celly is iets technisch iets beter mar dus wel kleiner.

* 786562 ThaVinny

[Verwijderd]

Ik spreek maar niet al te veel, en modereer ook maar niet, maar een beetje meer respect zo over en weer is ook wel eens lekker!
Iedereen maakt wel eens een denk/tel/lees/schrijffout, toch?

* 786562 rené

[Verwijderd]

ik weet dat jij altijd met weloverwogen post komt en daardoor heb jij bij de meeste tweakers (zeker bij mij) aardig wat aanzien. Maar deze gast snap niet waar het onderwerp over gaat en trekt meteen ze mond open over intel dit intel dat. ik probeer om zo aardig mogelijk terrecht te wijzen.

[Verwijderd]

Intel moet gewoon oprotten met z'n cache gezeik.

Dat moet je niet te hard roepen want ze hebben goed over nagedacht.
-Het gaat om de 8Kb L1 cache. Intel gebruikt een heel ander techniek, dit is bedoeld om een lage latency te krijgen wat hoge kloksnelheden garandeert.
-Je moet rekening houden dat ieder techniek zijn eigen specificaties heeft.
-Meer dan 8Kb heeft gewoon geen zin bij dit ontwerp.

The downside is the addition of a new class of faults, called way mispredictions, which can potentially sap IPC if they occur too frequently.

Dat is dus weer een nadeel wat de meesten nog niet weten..

intel heeft zich gericht op hoge kloksnelheden.
En heeft daardoor deze weg gekozen, het is ook niet mijn eerste keus maar hij heeft wel potentie..
Op 1Ghz is ie niet echt interessant maar ik denk dat je wel verleid zal worden door een term als : New, 2Ghz Pentium 4 !!

En als SSE2 breed toegepast wordt dan is het niet erg dat de FPU bagger is.

[Verwijderd]

Deze implementatie is misschien per saldo sneller... Maar het design van de PIV is wel vooral er op gericht om hoge kloksnelheden te halen (en wellicht om de "domme" op MHz gerichte klant over te halen iNtel te kopen)...

Maar deze discussie is al eens gevoerd (MHz tegen clock voor clock snelheid)...

[Erhnam]

Loki: b) niet sneller, maar simpelweg een truuk om te kunnen blaten dat je een 2GHz proc hebt terwijl de concurrent het "maar" met 1.5GHz moet doen?

Het is inderdaad een truuk, maar deze zal niet veel zin hebben. Je ziet het aan de CeleronII deze is zeer hoog te klokken maar zeker niet sneller dan bv. een duron op een veel lagere snelheid. Mensen kopen dan dus wel liever een cpu die op een wat lagere snelheid draait. De duron wordt daarom ook beter verkocht dan de celie2.

[Cyberdeck]

Ik vind het ook zeer vreemd maar het is wel een feit dat bij een bepaalde procstructuur er een max aantal cache is waarbij vergroten van het cache alleen maar negatief werkt. Ik weet verder niet hoe de structuur van de p4 eruit ziet, maar als ze de structuur dermate verbeterd hebben (door evetuele trukjes) zodat de optimale hoeveelheid cache lager komt te liggen dan tot nu toe gebruikt werd dan ligt her er nog maar aan hoe snel ie werkelijk is.
Standaard regeltjes zoals boven gebruikt hoeven voor een nieuwe structuur niet op te gaan. We zullen toch moeten wachten op de uiteindelijke tests.

[sonix666]

Ik merk dat het wel als marketing truuk wordt gezien om een processor uit te brengen die clock voor clock slechter presteert maar op hogere MHz draait.

Echter een grotere cache wordt zogenaamd weer niet gezien als een marketing truuk tov. een slimmere innovatieve cache architectuur die een kleinere L1 cache gebruikt.

Klinkt meer als dat we alleen Intel marketing strategieen als slecht zien.

Even over het eerste argument. Je kunt een processor op een gegeven moment maar zoveel procent sneller maken door hem clock voor clock te optimaliseren, maar helaas voor de mensen hier komt het uiteindelijk toch uit op de kloksnelheid. Je zult het echt niet zien gebeuren dat een 400 MHz x86 processor sneller is dan de x86 processor van de ander.

Stel dat je processor 10% langzamer is clock voor clock, maar door de nieuwe architectuur kan men juist 4 maal zo'n hoge kloksnelheden bereiken. Dan is daar in mijn ogen absoluut niets mis mee.