AMD whitepaper: alles over de Thunderbird cache

AMD heeft een whitepaper online gezet waarin uit de doeken wordt gedaan hoe de L1 en L2 cache van de Thunderbird werken. In het erg interessante artikel word onder andere verteld waarom AMD heeft gekozen voor een 64 bit brede bus richting de cache, wat de voordelen zijn van exclusive L1 cache en hoe het zit met de latencies. Kortom, bijzonder interessant voor de die-hard-tweaker. Als je besluit om het te lezen zul je wel een .pdf ready browser moeten hebben en/of Adobe Acrobat.

Bedankt [CoSD]Headbanger voor het submitten van dit nieuws!

Reacties (15)

[EfBe]

</div><div class=b4>
Processors with much smaller L1 caches <ed. note: Zoals de coppermine> need to be refilled more often and typically require a higher L2 bandwidth interface to help offset the shortcomings of their small L1 cache size
</div><div class=b1>
In welke situatie? bij grote datablock instructies? bij kleine loops? Totale zinloze opmerking van AMD, omdat cache refills / misses evenredig zijn aan de prediction, de pre-decoding steps etc.

Cache is leuk, maar voegt in veel gevallen niet veel toe (omdat binnen een stuk programmatuur veel variabelen middels veel code worden gewijzigd) of beter: wanneer je multiple threads op de CPU draait heb je met een grote cache nauwelijks meer voordeel dan met een kleine cache.

Next!

[Rukapul]

</div><div class=b4>
Cache is leuk, maar voegt in veel gevallen niet veel toe (omdat binnen een stuk programmatuur veel variabelen middels veel code worden gewijzigd) of beter: wanneer je multiple threads op de CPU draait heb je met een grote cache nauwelijks meer voordeel dan met een kleine cache.
</div><div class=b1>
Tav de opmerking over meerdere threads: het wisselen van processen en threads vindt niet zo vaak plaats (orde van grootte van ms), in die tijd zijn al enorm veel instructies uitgevoerd en is de cache dus al vaak gebruikt!
In het algemene geval geldt dat variabelen die echt veel gewijzigd worden door compilers normaal gesproken in registers worden geplaatst wat de eerste opmerking ontkracht.

Caches zijn onmisbaar vanwege de lokaliteit van code en data. Doordat verschillende stukken geheugen in verschillende delen van de cache worden geplaatst (dmv de tag-lines) zal zelfs het wisselen van thread niet altijd de gecachete data van een ander proces overschrijven.

Paul

[Jasper Janssen]

Juist als je multiple threads draait maakt een grote cache veel uit.

Xeon systemen (en Mustang straks) hebben niet voor niks grote caches.

Maar wat je ook doet, </div><div class=b4>Processors with much smaller L1 caches need to be refilled more often and typically require a higher L2 bandwidth interface to help offset the shortcomings of their small L1 cache size </div><div class=b1> is een truism. Hoe kleiner de cache, hoe vaker hij gerefilled moet worden. De impact kan verschillen met verschillende applicaties en gebruikspatronen, maar het keert zich nooit om.

[Jasper Janssen]

</div><div class=b4>
<..>extensive application performance testing shows that increasing the L2 bus width from 64 bits to 256 bits offers little or no significant impact to overall processor performance. Processors with much smaller L1 caches <ed. note: Zoals de coppermine> need to be refilled more often and typically require a higher L2 bandwidth interface to help offset the shortcomings of their small L1 cache size.
</div><div class=b1>

Ik weet het, ik weet het, AMD zegt het zelf dus hoe betrouwbaar is het... maar toch is het mooi dat AMD hetzelfde zegt als ik al weken zeg

[-=*skilla*=-]

gaaf technisch kontschoppen tegen intel.....
it's back to the drawing boards voor inhell

[Digistorm]

Otis,
o, dus jij zet je L2 cache gewoon uit? (kun je ook nog verder overklokken )
Natuurlijk heeft een grotere cache meer zin! Waarom denk je anders dat Xeons met 8MB cache geleverd worden.
En om het ff wat specifieker over jouw opmerking over AMD te hebben:
Wat AMD bedoelt is dat hun L1 cache veel groter is tov hun L2 cache, dus zal de L1 cache een groter deel van het cache-werk verrichten. Daarom is er een minder brede pijp nodig naar de L2 cache.

[Dennism]

</div><div class=b4>Natuurlijk heeft een grotere cache meer zin! Waarom denk je anders dat Xeons met 8MB cache geleverd worden.</div><div class=b1>

hmmmmm de grootste die ik ken heeft 2meg cache.

[Verwijderd]

de alpha heeft 8mb cache

xeon volgens mij ook maar 2mb uiterlijk 4mb

[Verwijderd]

misschien bedoeld hij dat 2 xeon 8mb hebben want waarom zou intel 8(!!!) mb op een processor gooien als er nu nog max 4 word gebruikt??

[tweakerbee]

Ik mis de AMD fans die hier altijd riepen, wacht maar tot de mustang met 256bits databus naar cache komt...

Blijkbaar heeft AMD dus niet nog een grote troef achter de hand, althans, niet deze. Wat wel mooi is, is dat ze met hun design een processor hebben ontwikkeld die goedkoper te produceren is, en evengoed presteerd als die van de concurrent, zodat ze het toch zullen winnen, helaas op prijs. Op prijs EN performance is vaak heel lastig, alhoewel AMD dat eventjes waar heeft gemaakt met de Athlon classic vs. Katmai.

Ik wil wel meer info over de Pentium IV. Wie weet wordt dat net zo'n flop als de i820...of niet....