Gå til innhold

Test: L2-størrelse på AMD = lite viktig

Bob Ibsen

Av Bob Ibsen
i Prosessorer

Anbefalte innlegg

Bob Ibsen

Bob Ibsen

Skrevet
Skrevet

Et av valgene man må gjøre når man skal kjøpe prosessor, er hvilken L2-mengde man skal gå for. Prisforskjellene har jevnet seg ut i det siste, men er det egentlig noe særlig ytelse å hente? I motsetning til på Intel-prosessorer vil man faktisk få en marginal ytelsesøkning av å doble L2-mengden til AMD. Dette kommer av forskjeller i arkitekturen, som jeg her forsøker å gi en forholdsvis enkel innføring i :)

 

 

Grunnleggende fellestrekk:

 

* Alt som skal behandles av prosessoren, hentes til L1-cachen og videre til registrene.

 

* Forespurte data søkes etter i følgende rekkefølge:

L1 --> L2 --> RAM --> I/O. Straks den ønskede adressen er lokalisert, vil de bli kopiert til registrene, og eventuelt L1 (hvis data kommer fra L2 eller RAM). Når data lokaliseres på et nivå, kalles det en cache hit. I motsatt tilfelle er det cache miss, og da må forespørselen sendes videre til neste nivå inntil dataene blir funnet.

 

* Cacheblokk eller cachelinje er en "datablokk" på 64 byte. Dette er den minste minneenheten som transporteres mellom L1, L2 og RAM.

 

* Cachemengde vil bli endel viktigere etter overgangen til 64-bits OS og software, men forholdene som påpekes her er generelle. Tendensene vil nok langt på vei være de samme, selv om skaleringen i forhold til størrelse kan endre seg.

 

* Alle størrelser har samme tilgangstider på K8. For Pentium4 er det en forskjell imellom Northwood (512kB) og Prescott (1024kB). Tilgangstidene er også forskjellige imellom de nyere utgavene som har 1MB og 2MB.

 

 

Pentium 4:

 

På en Pentium4 har L1 og L2 en dupliserende eller inkluderende relasjon - det betyr at alle ferdigbehandlede data som skrives fra registrene til L1, umiddelbart kopieres til L2 og RAM i tillegg. Det inkluderende cache-forholdet resulterer altså i at alle data som er i L1 også finnes i L2, og det reduserer den effektive lagringskapasiteten til cachene i sin helhet. Omtrent som en bok hvor noen av de samme setningene forekom på to steder - de ville ikke akkurat utgjøre noen ekstra informasjon. Å tilføre L3-cache med samme størrelse og arkitektur som L2 ville i denne sammenhengen vært udelt negativt. Det ville bare gjøre veien til minnet lengre (mer å søke igjennom), uten å bidra med noen nye data overhodet. Jo mindre størrelsesforskjellen imellom nivåene er, jo høyere er andelen av tapt *effektiv* lagringskapasitet. Derfor må det være et visst størrelsesforhold imellom L1 og L2 i dupliserende cacher. Intels løsning har vært å lage en liten L1, som til gjengjeld har svært lav søketid. Den høye klokkefrekvensen bidrar også til at L1 ikke blir et særlig stort hinder på veien til L2, som er en veldig kritisk faktor for Pentium 4. L2-mengden må være stor for å kompensere for den lille L1-cachen - ellers ville ikke cachene være i stand til å imøtekomme en stor nok andel av prosessorens forespørsler.

 

Den største fordelen til inkluderende cacher er følgende: Gjennomgående oppdatering innebærer at alle datablokker i cachen kan overskrives umiddelbart - det er ikke nødvendig å ta backup av gamle data i L1 før nye blokker hentes inn fordi dataene allerede er trygt forvart i både L2 og RAM.

 

 

 

AMD K7 og K8:

 

AMD-prosessorer bruker en ekskluderende cache-relasjon, som altså er det stikk motsatte av inkluderende. Her hentes data fra RAM til L1, og blir ikke skrevet tilbake til L2 før det er nødvendig av plass -eller konfliktshensyn. Vi kan se for oss at vi åpner en vannkran (data fra CPU), og plasserer et lite beger under den (L1 cache). Så har vi et ekstra beger under der igjen (L2 cache). Med visse forbehold og forenklinger kan vi si at L2 først vil få en aktiv rolle når det øverste begeret blir fullt og renner over. L2 vil da "samle opp" vannet i tilfelle det blir etterlyst senere - og i så fall må vi tømme de forespurte vannmolekylene tilbake i L1-begeret igjen :)

 

En ulempe med ekskluderende cache er at det krever en ekstra oppdatering idet en L1-miss inntreffer. Hvis det aktuelle området er opptatt må dataene vike plassen (eviction) og tas backup av før cachen kan oppdateres med de nye dataene. Derfor bruker AMD en victim buffer, som er en liten cache imellom L1 og L2. Data kan kopieres til denne samtidig som en forespørsel passerer videre til L2 (og eventuelt RAM), istedenfor å måtte flytte dem til L2 ved hver eneste L1-miss. Dette bidrar sterkt til å redusere ulempen ved ekskluderende forhold, uten at det eliminerer den. Når victim bufferen er full, må den nemlig kopieres til L2, og kapasiteten er så vidt jeg vet på bare åtte cachelinjer, eller 512 byte. Når victim bufferen må tømmes koster det åtte klokkesykluser, så dette hemmer effektiviteten til L2, om ikke dramatisk.

 

Fordelen med ekskluderende cache er først og fremst at det tillater en helt annen størrelse på L1, fordi L2 ikke "kaster bort" plass på å overlappe L1. Dette er en løsning som AMD har brukt i en årrekke, og den gir mye bedre fleksibilitet enn inkluderende relasjon fordi cachenivåenes størrelser ikke er "bundet" av hverandre. L2-cachen kan til og med være mindre enn L1 under denne arkitekturen, noe som faktisk er tilfelle med K7 Duron (128kB L1/64kB L2). L1 kan allerede romme så mye data at verdien av L2 blir neglisjerbar. Ekskluderende cacher gir dermed bedre muligheter for å skape en hel CPU-serie som yter nesten like bra over hele linja (det er alltid noen eksemplarer med delvis defekt cache). Den integrerte minnekontrolleren er også noe som bidrar til at cachestørrelsen blir mindre avgjørende for AMD, men de påfølgende grafene demonstrerer ikke dette siden de kun baseres på AMD K8-prosessorer.

 

 

 

 

Sammenligning av L2-størrelser på AMD K8:

 

Xbitlabs har laget en sammenligning av alle fire L2-størrelsene som er tilgjengelige på K8-serien, dvs 128, 256, 512 og 1024 kB.

Testen er utført med socket 754-prosessorer på 1,6 GHz, med samme minneklokke/timings.

 

sp.png

pcm04-1.png

pcm04-2.png

pcm04-3.png

3dm01.png

3dm05-1.png

3dm05-2.png

q3.png

ut.png

fc.png

d3.png

hl2.png

winrar.png

lame.png

mainconcept.png

divx.png

xvid.png

moldyn.png

3dsmax.png

 

 

http://www.xbitlabs.com/articles/cpu/print/sempron-2600.html

Lenke til kommentar

Videoannonse

Videoannonse
Annonse
whom

whom

Skrevet
Skrevet

Bra jobbet, en god og grundig test.

Har konkludert med det samme ved å lese tester.

Forskjellen i spill er minimal.

AMD 2,2ghz 512kb L2 ''Venice'' koster billigst 1721,-

AMD 2,2ghz 1024kb L2 ''San-Diego'' koster billigst 2323,-

Og da spør jeg dere, er det verdt mellomlegget på 602 kr? (og forskjellen var enda større før!)

Lenke til kommentar
Bob Ibsen

Bob Ibsen

Skrevet
  • Forfatter
Skrevet (endret)
Tror nok jeg ville addet et lite spørsmålstegn etter "Lite viktig".

Hovedpoenget mitt var egentlig å bevisstgjøre om at L2-størrelsens viktighet ikke kan sammenlignes på tvers av arkitekturer. En Celeron med 128kB mot Northwood med 512kB ville fått frem en annen målestokk, og forskjellene på AMD-siden blir små sett ifra den vinklingen.

 

Så forskjellen på 128kB Sempron og 256kB Sempron er faktisk mindre enn forskjellen på "San Diego" og "Venice". Jeg hadde faktisk trodd det var motsatt.

Ville også trodd at det var motsatt. Faktisk ser vi jo et par eksempler hvor det er minimal forskjell imellom 128 og 512, mens det plutselig kommer et hopp når det økes fra 512 til 1024 (3Dmark01 og Quake3).

 

 

Generelt synes jeg ikke at større cache er verdt å legge mye ekstra penger i. Selvsagt er det en forskjell, men det er jo "betryggende" å kunne konstatere at AMD-systemer klarer seg utmerket med liten L2-cache, og for den saks skyld med bare én minnekanal. Jeg håper vi får se Mobile Sempron i butikkene - det kan bety gode muligheter for fattigmannsklokking!

 

Takker for fin respons :thumbup:

Endret av Bob Ibsen
Lenke til kommentar
mar

mar

Skrevet
Skrevet

Er en vesentlig forskjell på L1 cache i Pentium 4 og A64 du har glemt. Pentium 4 lagrer ferdig dekodete instruksjoner i L1-i (instruksjons cache). Dette gjør at den slipper å dekode instruksjoner som alt finnes i L1. A64 må dekode alle instruksjoner, selv de som kommer fra L1 cache.

 

Problemet med denne L1 Trace cachen (som Intel kaller det) er at det er dyrt/vanskelig å stappe store mengder av den inn i en prosessor.

Lenke til kommentar
Bob Ibsen

Bob Ibsen

Skrevet
  • Forfatter
Skrevet (endret)
Er en vesentlig forskjell på L1 cache i Pentium 4 og A64 du har glemt. Pentium 4 lagrer ferdig dekodete instruksjoner i L1-i (instruksjons cache). Dette gjør at den slipper å dekode instruksjoner som alt finnes i L1. A64 må dekode alle instruksjoner, selv de som kommer fra L1 cache.

Utelatingen av trace cache var bevisst, fordi den er et resultat av den lange pipelinen snarere enn "interne" cache-trekk (selv om sammenhenger kan stikke dypt her). L1-størrelsen er jo den samme på alle prosessorer i samme serie, derfor blir det ikke noe som brukeren må være like bevisst på ved valg av modell. Pentium M benytter også inkluderende L1/L2-relasjon, men der så de det ikke som nødvendig/fordelaktig å innføre trace cache på grunn av andre forskjeller. Oversetteren (som koder instruksjoner om til microOps) sitter mellom L2 og L1 Trace Cache på Netburst-arkitekturen, slik at disse kan utnyttes flere ganger uten å måtte oversette dem på nytt. Dermed kan det så vidt jeg vet "hoppes over" åtte pipeline-trinn fra og med andre gang en instruksjon blir forespurt.

 

Hva med Intel sinde da?

Kunne jo laga samme greia med ES cpuer!

Tja, her blir vel tilgangstidene forskjellige, slik at sammenligningen ikke ville isolert mengdens påvirkning i samme grad. Forskjellen mellom 1 og 2MB er ikke så veldig stor - i en test jeg leste var doblingen nesten udelt negativ (pga økt latency).

 

Jevnt over 5-7% mer i spill med 1Mb cache i forhold til 512Kb.  Absolutt verd den ekstra prisen om ytelse betyr mye.

Sett ifra "ja-sidens" perspektiv er det verdt å merke at man faktisk får det største spranget ifra 512 til 1024. At det gir ekstra utslag i spilling gjør vel også sitt til at det blir ekstra interessant for en god del av brukerne her. Dette blir som alltid et spørsmål om hver brukers prioriteringer.

 

Uansett, vi snakker om en CPU-serie hvor L2-cachen har helt like tilgangstider på tvers av alle størrelser. Testen er ganske variert, og viser at en åttedobling i størrelsen bare gir 6% bedre ytelse i snitt, og 21% maks (DOOM3). Det tror jeg ikke mange ville ha gjettet :)

 

Så personlig konkluderer jeg fortsatt med at selv en socket 754 Sempron med 128kB er en høyst konkurransedyktig CPU - faktisk markedets beste prosessor-kjøp. Lav cachemengde og båndbredde ser heller ikke ut til å hemme skaleringen i forhold til klokkefrekvens i særlig grad.

 

Edit: rettet noe

Endret av Bob Ibsen
Lenke til kommentar
AndersT2

AndersT2

Skrevet
Skrevet

Har ett godt eksempel her. Min bror og jeg har ett meget ligt oppsett når det kommer til PCen.

 

Begge har Asus A8N-SLI Deluxe

Corsair PC4400 - 4x512

 

Jeg har en 3800+ (kjøpt i mars, og rett før winchester, venice og san diego kom)

 

Brodern har 4000+ kjøpt med feriepenger, tror det er venice han har. Forskjellen utad er egentlig 512 kb L2 mot 1 MB.

 

Når brett lastes inn i Battlefield 2 bruker jeg ca 45 sekunder, han ca 20-25 sekunder. Noe som er en ganske stor forskjell

 

En liten annen forskjell kan være at han har lagt inn BF2 på Raptoren, mens jeg har den på en vanlig disk. (Har raptoren som systemdisk begge 2)

Lenke til kommentar
  • 2 uker senere...
Simen1

Simen1

Skrevet
Skrevet (endret)
Uansett, vi snakker om en CPU-serie hvor L2-cachen har helt like tilgangstider på tvers av alle størrelser. Testen er ganske variert, og viser at en åttedobling i størrelsen bare gir 6% bedre ytelse i snitt, og 21% maks (DOOM3). Det tror jeg ikke mange ville ha gjettet :)

 

Så personlig konkluderer jeg fortsatt med at selv en socket 754 Sempron med 128kB er en høyst konkurransedyktig CPU - faktisk markedets beste prosessor-kjøp. Lav cachemengde og båndbredde ser heller ikke ut til å hemme skaleringen i forhold til klokkefrekvens i særlig grad.

Først: Utrolig god og informativ tråd :thumbup:

Edit: Jeg tillot meg å lage en samletråd over nyttige tråder om CPU'er og startet med å hedre din tråd: Annonsering: Nyttig lærdom om CPU'er.

 

Minnebåndbredden er også noe folk har hypet veldig mye opp. Moteordet "dual channel" har tydligvis mye mer slagkraft på kjøpere enn den reelle ytelseforskjellen. Jeg gjorde en tilsvarende sammenligning som du har gjort her med enkelt kanal minne og og doble minnekanaler og fant ut at gjennomsnittlig ytelseforskjell var ca 3%. Dette er sikkert også tall som de fleste vil bli overrasket over.

Endret av Simen1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
Gå til emneliste
×
×
  • Opprett ny...