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

[ATI vs GeForce]

Kommer det noen nye AMD prosesorer i nærmeste framtid?

[Bob Ibsen]

Kommer det noen nye AMD prosesorer i nærmeste framtid?

FX-59 vil muligens komme rundt årsskiftet. Sempron for socket 939 har også vært under produksjon en stund, men de er ikke tilgjengelige for løssalg føreløpig. Trolig vil dagens socketer til en viss grad stagnere, ettersom socket M2 (med DDR2-støtte) vil lanseres neste år.

[ATI vs GeForce]

Og disse FX cpuene blir vel å koste rundt 6000kr?

[Betroz]

FX-57 koster over 8000,- kr nå og FX-59 vil ikke koste noe mindre. De nye prosessorene for socket M2 vil koste det samme som de til 939 gjør nå.

[endrebjo]

FX-57 vil gå ut når FX-59 kommer (AMD vil ikke ha mer enn én FX på markedet samtidig), så da kommer nok FX-59 til å overta prisen på FX-57.

[Betroz]

FX-57 vil gå ut når FX-59 kommer (AMD vil ikke ha mer enn én FX på markedet samtidig), så da kommer nok FX-59 til å overta prisen på FX-57.

Tja FX-55 og FX-57 lever side om side fortsatt da...

[endrebjo]

FX-57 vil gå ut når FX-59 kommer (AMD vil ikke ha mer enn én FX på markedet samtidig), så da kommer nok FX-59 til å overta prisen på FX-57.

Tja FX-55 og FX-57 lever side om side fortsatt da...

AMD skulle ihvertfall ha sluttet å produsere den da de lanserte FX-57.

At produkter henger igjen på markedet vil jo alltid skje, men vi ser jo f.eks på komplett.no at FX-55 har en ubekreftet dato mens FX-57 er 10 stk av på lager.

[ATI vs GeForce]

FX-57 koster over 8000,- kr nå og FX-59 vil ikke koste noe mindre. De nye prosessorene for socket M2 vil koste det samme som de til 939 gjør nå.

Hva er det for slags socket? M2? Går ikke det på dette hovedkortet:

 

http://forum.hardware.no/index.php?showtopic=455838

[Frijazz]

Sokkel M2 er den nye sokkelen Amd lanserer rundt neste vår. Den vil ha støtte for DDR2-minne og den vil ikke være kompatibel med de andre soklene.

Sokkel M2.

[Jarmo]

Bob I. Vil du forklare litt mer om Barton og L1 hurtigbuffer 64Kb, L1 databuffer 64Kb og L2 Hurtigbuffer 512Kb ?

 

Tenkte spesielt på begge L1 buffere siden totalcachen oppgis som 640Kb..

Endret 8. oktober 2005 av jarmo

[Bob Ibsen]

Bob I. Vil du forklare litt mer om Barton og L1 hurtigbuffer 64Kb, L1 databuffer 64Kb og L2 Hurtigbuffer 512Kb ?

 

Tenkte spesielt på begge L1 buffere siden totalcachen oppgis som 640Kb..

"L1 Hurtigbuffer" kalles ofte for L1 instruksjons-cache, så har man altså data-cache i tillegg. Disse to adskilte blokkene er på 64kB hver, slik at det blir 640kB total cache når man regner med L2.

 

Det er svært vanlig å dele L1-cachen i to deler, en for data (informasjon som skal behandles), og en for instruksjoner (oppgavene som skal utføres). Caching har egentlig lite for seg hvis ingen data skal brukes på nytt før de må vike plassen og flyttes nedover til minnet igjen. "Reuse-rate" er derfor en viktig faktor, og denne graden kan variere veldig mellom forskjellige applikasjoner, men ikke minst imellom instruksjoner og data. Mediekoding er et godt eksempel på en oppgave som har noen få instruksjoner som konstant utføres på en "elv" av data som bare skal brukes en gang. Hvorvidt instruksjoner og data blir forespurt på nytt kan altså variere enormt. Av den grunnen kan det være fordelaktig å dele cachen i to fordi det gjør at tilgangen til data og instruksjoner blir uforstyrret av hverandre. Om det er konstant "gjennomtrekk" i den ene delen, kan man fortsatt bevare de hyppig brukte dataene i motsatt del slik at de ikke behøver å flyttes nedover i minnesystemet, noe som kunne blitt tilfelle i en udelt L1-cache.

 

Cachene på Barton er egentlig temmelig like de vi har på dagens K8-prosessorer. Så langt jeg vet dreier de arkitekturmessige forskjellene seg om en økning fra 64 til 128-bits L1-L2-buss og en dobling i TLB-størrelsen (Transfer Look-aside Buffer, som lagrer "pekere" fra virtuelle til fysiske adresser). Registrene er forskjellige i Athlon64s long mode, men de er ikke del av L1 eller L2. Jeg tror faktisk L1-cachen isolert sett har vært uforandret siden Athlon500.

Endret 8. oktober 2005 av Bob Ibsen

[Jarmo]

Takker for info, Bob I.

[Gjest Slettet+6132]

FX-57 vil gå ut når FX-59 kommer (AMD vil ikke ha mer enn én FX på markedet samtidig), så da kommer nok FX-59 til å overta prisen på FX-57.

Tja FX-55 og FX-57 lever side om side fortsatt da...

AMD skulle ihvertfall ha sluttet å produsere den da de lanserte FX-57.

At produkter henger igjen på markedet vil jo alltid skje, men vi ser jo f.eks på komplett.no at FX-55 har en ubekreftet dato mens FX-57 er 10 stk av på lager.

Helt korrekt..

At en Webshop/Leverandør har en vare i sortimentet betyr ikke at du med sikkerhet kan få den levert..

Typisk på utgående (produksjonsopphør) vil det kun være evt. restede varer man kan få tak i..

"Ubekreftet dd.mm.yyyy" er av og til ensbetydene.. med at aktuell vare ikke er å få tak i (i slike tilfelle)..

[Anders Jensen]

Bob Ibsen: Nå har jeg ikke lest hele tråden og har bare skummet gjennom første post, men jeg fikk inntrykk av at du forklarer viktigheten av L2 cache, eller rettere sagt mangelen på sådan, for K8 er at den ved å være eksklusiv ikke har mye innvirkning på ytelsen. Dette virker ikke som en veldig god forklaring. Jeg vil anta at den store L1 cachen og den relativt lave main memory forsinkelsen er årsaken til at forskjellige L2 størrelser ikke gir så stort utslag i ytelse.

 

Begrunnelsen er enkel:

1) den store L1 cachen reduserer L2 hits

2) den korte main memory forsinkelsen reduserer gevinsten på en L2 hit

 

Benytt Amdahls lov eller intuisjon her og du vil nok se at dette er riktig og bygger opp under en konklusjon om at L2 størrelsen på k8 ikke bør ha like mye innvirkning på ytelsen som på en del andre vanlige design (f.eks P4 som har en del mindre L1 cache og en del høyere main memory forsinkelse).

 

For veldig små størrelser av L2 vil jo det å ha eksklusiv L2 medføre at den blir viktigere for ytelsen enn ved inklusiv L2 cache, ikke motsatt.

Endret 9. oktober 2005 av Anders Jensen

[Bob Ibsen]

Bob Ibsen: Nå har jeg ikke lest hele tråden og har bare skummet gjennom første post, men jeg fikk inntrykk av at du forklarer viktigheten av L2 cache, eller rettere sagt mangelen på sådan, for K8 er at den ved å være eksklusiv ikke har mye innvirkning på ytelsen. Dette virker ikke som en veldig god forklaring.

For å vinkle det litt annerledes: Ekskluderende cacher tillater bruk av større L1 enn inkluderende, fordi L2 ikke overlapper L1. Dette er også forklart i startinnlegget. AMDs store L1-cache henger jo utvilsomt sammen med det ekskluderende forholdets natur, og derfor blir cacherelasjoner en uunngåelig del av gjennomgangen.

 

Det er selvsagt riktig at ekskluderende relasjon i seg selv ikke hjelper stort hvis man ikke samtidig utnytter fordelene det åpner opp for. Cacherelasjoner er jo svært avgjørende for hvilke effektive størrelsesforhold og kombinasjoner det blir å velge i, og harmonien må jo uansett være tilstede for at et design skal bli effektivt. Så selv om det ikke ligger noen absolutt automatikk i sammenhengene jeg påpeker, mener jeg at de er nokså vanntette så lenge man holder seg innenfor rimelighetens grenser.

 

Men hvis noen skulle designe en ekskluderende cache uten å samtidig benytte seg av muligheten til å innføre ekstra stor L1, ville det ikke ligge noe automatisk ”hokus-pokus” i det.

 

Jeg vil anta at den store L1 cachen og den relativt lave main memory forsinkelsen er årsaken til at forskjellige L2 størrelser ikke gir så stort utslag i ytelse.

Begge punktene er forsåvidt direkte nevnt i startinnlegget, men det med minnekontrolleren ser jeg på som en medvirkende faktor, snarere enn en forutsetning for fenomenet. L2 prefetching (som kan utføres når minnebussen idler, såvidt jeg vet også på K7), og økt L2 success-rate som følge av størrelsesøkningen har en viss innflytelse, men den store L1-mengden er som du sier det viktigste.

 

For veldig små størrelser av L2 vil jo det å ha eksklusiv L2 medføre at den blir viktigere for ytelsen enn ved inklusiv L2 cache, ikke motsatt.

Her ser jeg ikke helt hvor du vil hen.

 

Som du vet: I inkluderende cacher kan ikke L2 være mindre enn L1, og om de er like store vil jo L2 være helt meningsløs (ihvertfall sett ifra et rent kapasitetsperspektiv). Om L2 da er ”veldig liten” må nødvendigvis den totale/effektive cachestørrelsen også bli veldig liten, med alle ulemper det innebærer.

 

Å tenke seg en fastsatt, liten L2-mengde under begge relasjonene ser jeg derfor på som ganske uinteressant i praksis, fordi L1-størrelsen av naturlige årsaker ville ha variert mye mellom de to designene. En liten, inkluderende L2 ville påtvinge en enda mindre L1 - noe som ikke er tilfelle for ekskluderende forhold. Forøvrig har L1-størrelsen generelt så stor betydning for L2s ”belastning” at jeg synes det blir nokså vanskelig å isolere og sammenligne.

 

En inkluderende L2 vil jo alltid ha en viss ”L1-skygge”, avhengig av størrelsesforholdet mellom nivåene. Altså vil success-raten isolert sett være lavere for en inkluderende L2-cache, enn for en ekskluderende av samme kapasitet. Hvis L2 bare er litt større enn L1 vil ikke L2 kunne romme mye ”ekstra” data, så jo mindre den er, jo mindre innflytelse vil den på sett og vis ha på ytelsen (les: mindre grad av positiv effekt). Skulle mengdeforskjellen mellom L1 og L2 være så liten at bare noen sjeldne få L2-hits kunne inntreffe, ville nivåets verdi blitt neglisjerbar. I så fall kunne ikke nivået sies å være direkte viktig, rett og slett fordi det ville gjort liten nytte for seg i utgangspunktet. Men da vil jeg heller vinkle det andre veien og si at en økning i L2-størrelsen likefullt vil gi en klar ytelsesgevinst.

 

Tar forbehold om misforståelser

Endret 10. oktober 2005 av Bob Ibsen

[Anders Jensen]

Hm det var merkelig at du var så ressistant mot mine synspunkter. Jeg kommer imidlertid ikke til å kjøre de en gang til. Når det gjelder valg av eksklusiv cache som en forutsetning for stor L1 cache så har jeg heller ingen tro på den årsakssammenhengen. Det kan kanskje høres ut som et høna og egget problem, men det er det ikke. Når en gjør design trade-off så har en jo gjerne flere fullstendige løsninger å velge mellom, så hva jeg skisserer her må tas under forrutsetning av at en allerede har bestemt seg for å lage et kjernedesign som kan håndtere relativt høye forsinkelser til L1 cache uten nevneverdig tap av ytelse (K7, K8 og PM er eksempler på slike). La oss f.eks annta at en kan nøye seg med 3 syklus tilgangstid 2 reads/cycle og 2 writes/cycle og har en moderat klokkefrekvens. Da gjenstår det å velge en kombinasjon av assosiativitet og kapasitet som en får skviset inn under gitte forutsetninger. Siden en har nøyd seg med relativt slapp timing (3 sykluser) så får en nokså stor kapasitet selv ved rimelig høy assosiativitet, noe som er et argument for å velge eksklusiv L2 cache spesielt om en er veldig interessert i å spare silisium areal. Hvis en også skal optimalisere for singel CPU systemer er det i seg selv enda et argument for å velge eksklusiv L2 siden en får mer utav hver transistor og slipper multi-CPU straffen ved bruk av eksklusiv L2 cache. Altså at L1 cache blir veldig forstyrret av andre prosessorer i systemet fordi hver eneste cahce coherency transaksjon må lese L1, mens en ved bruk av inclusive cache kan stoppe forespørselen i L2 hvis linja ikke er å finne i L2.

 

Valg av eksklusiv L2 cache er altså påvirket av mange faktorer, hvorav noen er beskrevet her. Stor L1 cache er også et argumet for å velge eksklusiv L2 cache, men eksklusive L2 cache er IKKE et argument for å velge stor L1 cache. Det er en viktig nyanse. L1 cache er tett knyttet til kjernen og betraktes gjerne som en del av kjernen. Design trade-off i L1 cache er utelukkende styrt av kjerne designet og overhodet ikke styrt av lavere nivå i minnehierarkiet. Det er heller resten av minnehierarkiet som må føye seg etter kjerne og L1 designet.

Endret 10. oktober 2005 av Anders Jensen

[Jarmo]

Hei Anders

 

Er det slikt å forstå at dagens L1/L2 cache struktur og virkemåte kan optimaliseres mer enn vi ser i dag ? Og eventuelt hvordan ?

Endret 10. oktober 2005 av jarmo

[Anders Jensen]

Hei Anders !

 

Er det slikt å forstå at dagens L1/L2 cache struktur og virkemåte kan optimaliseres mer enn vi ser i dag ? Og eventuelt hvordan ?

Det er jo en haug av mulige optimaliseringer, men de fleste er litt slik vinn/tap optimaliseringer hvor en altså må gi litt for å tjene på noe annet. Det er også slik at betingelsene for optimalisering er under konstant forandring. For eksempel er ytelse/watt i ferd med å bli viktigere enn ytelse/areal. Det er også et konstant økende gap mellom cpu ytelse og minne ytelse som gjør at det å bruke mer ressurser på cache kan være lønnsomt og en har mulit core tendensen som har en del konsekvenser for hva som er fordelaktig å implementere. En bør også skille litt mellom singe sokkel og multi sokkel løsninger. Hva som lønner se i de to tilfellene kan variere veldig mye og i noe grad være motstridende. Det vil ha konsekvenser for design som er ment å kunne fungere i begge disse typer systemer.

 

Jeg ser for meg følgende utviklingstrender:

 

1) Cache vil bli høyere prioritert fordi ytelse/watt overstyrer ytelse/areal og fordi CPU/minne gapet øker.

 

2) Cache hierarkier vil bli skreddersydd for flere kjerner

 

3) Det vil bli mer vanlig å designe for singel sokkel løsninger for seg selv og multi sokkel løsninger for seg selv i motsetning til hva vi ser i dag med Athlon/opteron og P4/xeon som deler samme type design.

 

Det vi kan vente oss og som allerede er synlig i forskjellige veikart er:

 

1) Delt LLC (last level cache) blir vanlig.

 

2) Større delt L2 cache blir vanlig i singel sokkel systemer.

 

3) Multisokkel systemer får mindre L2 cache enn singel sokkel systemer men får stor delt L3 cache og altså ikke delt L2 cache. L1 vil nok være inklusiv i L2 for å redusere presset på L1 i disse systemene. Det kan imidlertid se ut som om noen multi sokkel design vil satse på stor delt L2 cache og droppe L3 cache fullstendig. Dette vil nok avhenge en god del av hva slags kjerne og L1 design en har. F.eks er Itanium avhengig av en svært rask (1 syklus tilgangstid) L1 cache som dermed blir veldig liten. Det medfører at en må ha en egen L2 cache for å makte å fore L1 og kjernen raskt nok. Det er altså veldig avhengig av CPU designet hvordan cache designet bør se ut selv i samme type maskiner.

 

4) Harvard style L2 cache (I-cache og D-cache) kommer til å bli brukt for å øke båndbredde og kapasitet samt holde tilgangstidene nede. Dette er en typisk konsekvens av at cache blir en viktigere komponent, men vil nok bare være aktuelt der en også har L3 cache.

 

Ellers vil det nok bli en del tettere koblinger mellom kjerner på samme brikke. I dag er denne typisk etter L2 eller L3 cache. I fremtiden vil vi se direktekobling mellom L1 cache for kjerner på samme chip. Dette gjelder i alle fall for neste gen Intel DC. Om det blir en trend på multicore er nok heller tvilsomt da det blir veldig dyrt å koble sammen mange L1 cache systemer. Kanskje vil de bli koblet sammen to og to eller at de er koblet til en egen ring for cache coherency på chipen. Uansett er ikke koblingen mellom kjernene internt på chipen veldig viktig i multi sokkel systemer. Det er først og fremst i singel sokkel systemer at denne koblingen kan utgjøre en nevneverdig forskjell.

[Del]

Hvis en også skal optimalisere for singel CPU systemer er det i seg selv enda et argument for å velge eksklusiv L2 siden en får mer utav hver transistor og slipper multi-CPU straffen ved bruk av eksklusiv L2 cache. Altså at L1 cache blir veldig forstyrret av andre prosessorer i systemet fordi hver eneste cahce coherency transaksjon må lese L1, mens en ved bruk av inclusive cache kan stoppe forespørselen i L2 hvis linja ikke er å finne i L2.

Dette er et godt poeng, dette gjelder jo spesielt for 800-serien til Opteron, og er kanskje forklaringen på at vi har sett få eller ingen 8-sokkel maskiner basert på Opteron. Cache coherency gir kanskje en performance hit allerede på 4-sokkel Opteron, men jeg har ikke sett noe håndfast på dette. På singel sokkel eller dual tror jeg neppe det har særlig negativ effekt.

Uansett er ikke koblingen mellom kjernene internt på chipen veldig viktig i multi sokkel systemer. Det er først og fremst i singel sokkel systemer at denne koblingen kan utgjøre en nevneverdig forskjell.

Dette har jeg grublet litt på, og tror du har rett. I utgangspunktet kunne man jo sett for seg, selv på multi-sokkel oppsett, at man utnytter den kjappere kommunikasjonen mellom kjernene ved DC. Men jeg kan vanskelig se for meg at dette vil bli utbredt, hovedsaklig av to grunner. Den ene er at en slik kode vil bli veldig systemspesifikk, og det er vel ganske langt fra dagens trend. Den andre er det rent praktiske, hvordan skal du organisere problemet ditt slik at de operasjonene som trenger kjappest kommunikasjon kommer i par, hvis det overhodet er mulig. Om det er mulig så tror jeg det vil være rimelig speiselle tilfeller. Hvis ikke må kjøringen uasnett vente på de operasjonene som blir sist ferdig, før den kan gå videre. På singel-sokkel er dette ikke noe problem, siden all kommunikasjon skjer med samme kjappe hastighet.

 

Bob Ibsen, takk for en meget god tråd.

[Anders Jensen]

Dette er et godt poeng,[]

Joda, takker. Kan verken påstå at det er kontroversielt eller noe jeg har kommet på selv. Det er tatt rimelig rett ut av læreboka.

Dette har jeg grublet litt på, og tror du har rett. I utgangspunktet kunne man jo sett for seg, selv på multi-sokkel oppsett, at man utnytter den kjappere kommunikasjonen mellom kjernene ved DC. Men jeg kan vanskelig se for meg at dette vil bli utbredt, hovedsaklig av to grunner. Den ene er at en slik kode vil bli veldig systemspesifikk, og det er vel ganske langt fra dagens trend. Den andre er det rent praktiske, hvordan skal du organisere problemet ditt slik at de operasjonene som trenger kjappest kommunikasjon kommer i par, hvis det overhodet er mulig. Om det er mulig så tror jeg det vil være rimelig speiselle tilfeller. Hvis ikke må kjøringen uasnett vente på de operasjonene som blir sist ferdig, før den kan gå videre. På singel-sokkel er dette ikke noe problem, siden all kommunikasjon skjer med samme kjappe hastighet.

Jepp, jeg har grublet på dette jeg også og kom vel egentlig til nøyaktig samme resonnement og konklusjon. Dette er imidlertid ikke tatt ut fra læreboka, men mer basert på intuisjon. Jeg har imidlertid fundert på om det ikke ville være mulig å la hardware inneholde en slags "nodekontroller" som kunne leses av OS. Det kunne fungere slik at hver chip (det være seg CPU, gluelogic/chipset, I/O osv. kanskje AMB også?) hadde en slik "nodekontroller" som holdt styr på alle ressurser internt på brikken samt alle linker til andre brikker med et parametersett som beskriver linkkapasiteten. Dermed kunne OS lese ut hardware som en graf med ressursnoder og vektede kanter. Det ville gitt OS en mulighet til å forholde seg veldig dynamisk og generelt til hardware. Programmer kunne så fortelle OS hvilke tråder som hadde behov for mye kommunikasjon mot hverandre og sørget for at de kjørte på nærliggende hardware. Denne teknikken kan sees på som en utvidet NUMA støtte i både hw og os. Til en viss grad er dette utbredt i superdatamaskiner i dag. Særlig SGI har en del ekstra funksjonalitet som går i denne retningen noe som henger nokså tett sammen med deres ledende posisjon innen shared memory systemer og SSI dimensjoner.

 

http://www.sgi.com/products/software/linux/propack.html

Det er riktignok snakk om noe grovere sortering. Ikke har de tilgang til dual/multicore ennå heller...

Endret 11. oktober 2005 av Anders Jensen