AMD Thunderbird met 16-way set associative cache

AMDRulez schrijft dat er op deze wazige Japanse site staat dat de Thunderbird 16-way set associative cache gaat krijgen, iets wat volgens die site evengoed presteert als 512 kilobytes aan 4-way set associative cache :

Ter vergelijking: de Coppermine heeft 8-way set associative cache en de Celeron II heeft 4-way set associative cache. Het verschil tussen 4-way en 8-way verklaart voor een deel de enorme performance verschillen tussen de Celeron II en Coppermine dus 16-way is wel fijn .

Reacties (22)

[Anoniem: 1795]

Dit lijkt me duidelijk toch? Beter dan wazige beloften. AMD is tot nu toe al zijn beloften nagekomen en nu weer, die screenshot is heus niet gefaket, daar heeft AMD niets aan.

[Wietse.]

16-way set associatief betekent dat per hoofdgeheugengebiedje 16 blokken tegelijk in de cache opgeslagen kunnen worden. Als je 1-way set associatief (direct) cache hebt is er per hoofdgeheugengebiedje maar 1 plek in de cache.

Het komt er zo'n beetje op neer dat in het geval van 16-way de cache veel effectiever wordt gebruikt, waardoor er vaker een cache hit optreedt: de gevraagde data staat ook werkelijk in de cache.

Natuurlijk kost 16-way wel meer hardware dan 1-way.

[JeroenB]

Dr. Vork: Een set-associative cache is een direct-mapped cache met meerdere Tag-entries per cacheline, zodat er in de cache meerdere stukken data kunnen staan op dezelfde Line.

Om dan te bepalen welke je moet hebben, moet je dan dus door alle entries heenlopen om te kijken of de juiste Tag erbij zit. Bij een 16-way associative cache kan je dus 16 keer moeten vergelijken en dan alsnog naar het geheugen moeten. Tegelijkertijd is de kans 16x zo groot (hoewel dat niet vaststaat, het enige dat vaststaat is dat er 16x zoveel Lines in kunnen) dat je uberhaupt niet naar het geheugen moet tov een standaard (1-way) cache.

Opzich is het logisch dat naarmate cache-sizes vergroten, de hoeveelheid associative entries ook vergroten. Probleem is alleen dat er ERG veel "bookkeeping" komt kijken bij de integriteitsbewaking van je cache. En als je niet oppast kan je systeem alleen maar langzamer worden (als je bijvoorbeeld continue in serie uit 17 of meer totaal verschillende stukken geheugen leest, dan gaat'ie massaal over de zeik, aangezien je dan steeds 16x die hele cacheline moet doorlopen op Tags en daarna ALSNOG uit mem moet lezen.)

Probleem is bijvoorbeeld: welke Tag knikker je eruit bij een cache-miss? De minst recent gebruikte? Die lijst moet je dus wel ELKE geheugenoperatie bijwerken, niet alleen op een cache-miss...

[Anoniem: 3380]

Ok das leuk om te horen dat ze dus nog geavanceerdere cache gaan gebruiken, maar hoe zit het dan het de latency van deze cache?
weet iemand daar iets van. ik dacht dat de coppermines L2 cache een latency van 6 had, maar weet niet zeker. Dit is natuurlijk ook belangrijk zeker als de cache klein is(256K noem ik niet groot)dan moet deze snel kunne benaderd dus is het belangrijk dat er een zo laag mogelijke latency is. Wat gaat AMD hier tegen doen. zelfde snelheid? sneller? of langzamer? als je het weet post dan ff

[Hielko]

De coppermine heeft een latency van 0, en de celeron 2 heeft er een van 2.

De latency van de thunderbird kent niemand (zover ik weet) maar waarschijnlijk wordt het 0.

[Anoniem: 3380]

Ik dacht toch echt ergens te hebben gelezen dat het 6 was hoor want 0 kan volgens mij niet. Volgens mij is die 0 gebaseerd op NS en die 6 op MS(das toch kleiner). Ik heb ff een P3 datasheet gedl maar ze hadden het wel over de ATC maar niet over de latency hiervaan dit is wat ze zeggen:

Non-Blocking, full speed, on-die level 2 cache
8-way set associativity
256-bit data bus to the level 2 cache
Reduced latency interface to cache data (as compared to discrete caches)

dit is wat de athlon krijgt(niet alles is al bekend)

Non-Blocking, full speed, on-die level 2 cache
16-way set associativity
256-bit data bus to the level 2 cache
Reduced latency interface to cache data (as compared to discrete caches)
dat laatste lijkt me duidelijk want het is gewoon zo dat als je de cache ondie plaatste dat de data dan sneller is dus een lagere latency. ik schat dat de lateny van de athlon het zelfde zal zijn als die van P3.

[Anoniem: 3380]

Nu we weten dat de thunderbird dus 16way is.
komen we bij een punt wat wietse opmerkte de grote. Groter is grotere prijs. En nou had de spitfire een 99mm^2 core dus dat is maar een klein stukje kleiner dan de coppermine's 106mm^2 core. Nou is de vraag hoe groot wordt de core van de thunderbird? kijk de athlon core was al groter dan die van de katmai en ook groter op 0.18µ dan de coppermine op die grote. Nou voegen we 256K 16way cache erop enhanchen de core een beetje en dan krijg je dus een grotere core. De vraag is hoe groot want: hoe groter de core hoe minder per wafer en dus hoe minder ze verdienen per wafer en hoe meer wij moeten betalen. Hopelijk zorgt het feit dat je geen off die cache meer hoeft toe tevoegen(Die ze commercieel en dus vrij duur moesten kopen)ervoor dat de thunderbird even duur blijft. als dat zo is zal de socket versie een paar tientjes (2 tot 3) goedkoper zijn dan de athlon classic omdat deze geen cardridge heeft.

[JumpStart]

ThaVinny:

Je vergeet hetvolgende in de vergelijking mee te nemen: hoeveel lagen gaan er gebruikt worden in het productie proces ??? Ter vergelijking: met de overgang van de Katmai core naar de Coppermine werden er ook meerdere lagen gebruikt.

Voeg je een extra laag schakelingen toe, dan kan je met minder oppervlakte toe, maar is er een extra bewerking (of meerdere, wanneer je 2 of meer lagen extra gaat gebruiken) in je productie proces nodig. (En er is een of meer masks nodig. )

De andere kant die je dus op kan gaan is meer lagen: evenveel cores uit een wafer, maar mogelijk wel een lagere yield: meer lagen = complexer = meer kans op een fout.

[Anoniem: 5565]

goed voor dpc go dpc !!!!!!!!
dpc rulez!!!!!!!!
mooooooooo!!!!!!!!!!!!!!

[Anoniem: 6182]

Hmmz...dat ziet er kontschoppend uit, meer kan ik voorlopig nog niet erover zeggen...