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

[Blib]

Bob Ibsen, utrolig bra lesestoff. Var ikke klar over at forskjellen var så liten selv (Selv om den for meg er verdt det), og jeg hadde satt stor pris på flere slike poster fremover. Nydelig arbeid

 

Edit: Forresten, K8, er det prosessorene før A64? Altså XP?

Endret 21. september 2005 av Blib

[Simen1]

Edit: Forresten, K8, er det prosessorene før A64? Altså XP?

Nei, det er kjernefamilien som alle AMD64-prosessorer er basert på. Altså alle prosessorer som bruker sokkel 754, 939 og 940 (og de kommende sokkel S1, M2 og F2) Edit:

 

Noen kaller AMD's dobbeltkjerner for K9 selv om det i bunn og grunn nesten ikke er noen arkitekturmessige forskjeller mellom den og K8 bortsett fra at det er lagt til en ekstra K8-kjerne.

 

AthlonXP, Athlon MP, Athlon, og Duron er basert på kjernefamilien K7.

Endret 21. september 2005 av Simen1

[Bob Ibsen]

Først: Utrolig god og informativ tråd

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.

Takk

 

Jeg hadde også en tråd som sammenligner single -versus dualchannel her.

 

Eneste virkelige forskjellen er i båndbredden, som jo isolert sett er svært lite interessant. Skal man måle ytelse på biler, er det jo mer enn antall hestekrefter som betyr noe. Noen biler veier jo f.eks. mer enn andre, og i sammenhengen minnebåndbredde og L2-størrelse er det utvilsomt Intel-systemer som "veier mest"...

[2 Fast 4 Biltema]

fin tråd

[blackbrrd]

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).

Dette har sine logiske grunner...

 

La oss si at du har et program på 800kbyte... Når du kjører programmet så hopper du fram og tilbake i programmet hele tida og må derfor ha tilgang til 800kb data..

 

Hvis du har 512kb L2 cache (og 128 L1 cache) så er dette akkurat for lite til at du kan ha det i L2 cachen. Har du 1mb L2 cache, så holder det...

 

Data som modeller/terreng osv er gjerne for store for L2 cachen samme hva, så hvis cpu'n er smart nok så blir ikke disse liggende i L2 cachen på bekostning av mer ofte brukt data som f.eks instrukser.

 

Jeg tenker at de fleste programmer har ett "ytelseshopp". Dvs at ytelsen øker jevnt og trutt med mengden L2 cache helt til en essensiel del av programmet passer helt inn i L2 cachen og ytelsen øker markert. Deretter fortsetter ytelsen å øke med mengden L2 cache, men såvidt merkbart ettersom hoveddelen av programmet nå ligger i L2 cachen.

[Bob Ibsen]

fin tråd

Takk!

 

Dette har sine logiske grunner...

 

La oss si at du har et program på 800kbyte... Når du kjører programmet så hopper du fram og tilbake i programmet hele tida og må derfor ha tilgang til 800kb data..

 

Hvis du har 512kb L2 cache (og 128 L1 cache) så er dette akkurat for lite til at du kan ha det i L2 cachen. Har du 1mb L2 cache, så holder det...

 

Data som modeller/terreng osv er gjerne for store for L2 cachen samme hva, så hvis cpu'n er smart nok så blir ikke disse liggende i L2 cachen på bekostning av mer ofte brukt data som f.eks instrukser.

 

Jeg tenker at de fleste programmer har ett "ytelseshopp". Dvs at ytelsen øker jevnt og trutt med mengden L2 cache helt til en essensiel del av programmet passer helt inn i L2 cachen og ytelsen øker markert. Deretter fortsetter ytelsen å øke med mengden L2 cache, men såvidt merkbart ettersom hoveddelen av programmet nå ligger i L2 cachen.

Joda, alt har sin logiske forklaring, men jeg ville fortsatt trodd at forskjellen mellom 128kB og 512kB skulle være større, fordi en større andel av de mest nødvendige dataene selvsagt kan caches med 512kB. Således burde det jo bli færre minne-henvendelser, selv om ikke hele programmet får plass i cachen. Dette handler nok om data snarere enn instruksjoner, fordi data i de fleste tilfeller vil ha mye lavere reuse-rate enn instruksjoner. At minneytelse har større betydning i spill enn i mange andre applikasjoner tyder også på dette.

 

L1 har jo også en dedikert Instruksjons-cache, og i akkurat denne sammenhengen ser jeg uansett ikke at L2-størrelsen skal hjelpe nevneverdig, fordi en evicted instruksjon trolig blir forespurt igjen før den må flyttes ned fra L2 til RAM i de fleste tilfeller. Instruksjoner/data som er hyppig brukt er også de som vil få høyest prioritet, da en vanlig replacement policy er LRU (Least Recently Used) - altså at blokken som sist var i bruk blir nedprioritert når cachen må rydde plass til nye data. Poenget med caching er egentlig at man tar høyde for at dataene skal bli brukt igjen, slik at prosessoren får mye raskere tilgang til dem neste gang. Data som bare skal brukes en gang (f.eks. en musikkfil som spilles fra begynnelse til slutt) kalles da for cache polluter. Mye data blir cachet til liten nytte, og det samme fenomenet gjelder for spilling. Selvsagt ikke i fullt så stor grad men fortsatt nevneverdig, fordi data hele tiden må skiftes ut, og flyttes frem og tilbake. Maskinen "vet" ikke hva du har tenkt å gjøre - spilling er som regel en lite forutsigbar oppgave når det gjelder f.eks. hvilke modeller som trengs. Om du svinger til høyre eller venstre i et bilspill kan ikke prosessoren vite på forhånd, men det kan få store konsekvenser for hvilke data som trengs. Instruksjonene, blant annet for manøvrering og fysikkberegning, vil myegodt gå igjen uavhengig av det.

 

Filmkoding er et eksempel på en særdeles forutsigbar oppgave, hvor både working set passer i L1-I, og datastrømmen kan hentes i en forutbestemt og uforanderlig rekkefølge. Testen viser jo også praktisk talt null forskjell når det gjelder disse applikasjonene.

 

Når det gjelder L1-cachen på AMD-prosessorer er det ikke fysisk plass som er den fremste begrensningen sammenlignet med andre prosessorer, men at de har lav associativity. Dette gjør at bare to blokker i RAM kan hentes til samme L1-sett til enhver tid - absolutt alle minneaddresser har bare to fastsatte blokker de kan caches i (16 for L2). Dette gjøres for å holde søketiden på et lavt nivå - jo flere blokker hvert sett består av, jo mer må søkes igjennom for hver forespørsel. Men at hver minneadresse har to tilhørende cacheblokker betyr selvsagt ikke at alle adressene må kjempe om de samme to cacheblokkene. Derimot kan det medføre endel flytting imellom cachene fordi det gir flere såkalte conflict misses - når disse inntreffer hjelper det ikke om resten av nivået (hypotetisk sett) er helt ribbet for data. Dette handler også om hvordan "ren" og veltilpasset programvaren er.

 

(dette med associativity finner jeg temmelig vanskelig å forklare)...

 

 

Edit: innlegget er noe "justert"

Endret 23. september 2005 av Bob Ibsen

[Simen1]

Bob Ibsen: Tror du det hadde gitt noe mening om AMD innførte et nytt cachenivå mellom L1 og kjernen? Jeg tenker da at dagens L1 er ganske treg fordi den er så stor. Kunne det gjort seg med f.eks en liten (8 kiB?) inclusive instruksjonscache med ferdigdekode instruksjoner?

 

En annen ting: Kunne det vært en idé å innføre et nytt L3 cache-nivå i form av en "ekstern" DRAM-brikke på Operon-serien. F.eks implementert som en MCM (Multi Chip Module) med en spesialdesignet DRAM-brikke under lokket på CPUen. F.eks en med 1024bit bussbredde og et rask DDR3-minne på f.eks 16-32 MiB. ?

[Bob Ibsen]

Bob Ibsen: Tror du det hadde gitt noe mening om AMD innførte et nytt cachenivå mellom L1 og kjernen? Jeg tenker da at dagens L1 er ganske treg fordi den er så stor. Kunne det gjort seg med f.eks en liten (8 kiB?) inclusive instruksjonscache med ferdigdekode instruksjoner?

Ferdigkodede instruksjoner - mener du et lager for microOps, dvs noe à la Intels trace cache, bare at oversetteren skulle vært mellom L1 og vår forestilte "L0"?

 

Størrelse er en ting, men AMDs lave associativity gir jo en fordel med tanke på antallet tags som må sammenlignes per søk. AMD oppgir L1-latency til tre sykluser, som er i samsvar med målinger jeg har sett. Lav associativity i kombinasjon med den store mengden gir naturlig nok mange frames/sets, men jeg har ikke trodd at dette påvirker søketiden. John Stokes på Ars får det heller ikke til å høres slik ut:

 

Furthermore, since all the sets consist of exactly four blocks, no matter how big the cache gets we'll only ever have to search through four frames (or one set) to find any given block. This means that as the cache gets larger and the number of sets it can accommodate increases, the more efficient the tag searches get. Think about it. In a cache with three sets, only 1/3 of the cache (or one set) needs to be searched for a given block. In a cache with four sets, only 1/4 of the cache is searched. In a cache with 100, four-block sets, only 1/100 of the cache needs to be searched. So the relative search efficiency scales with the cache size.

Hva han mener er altså at økt størrelse og dermed flere frames i seg selv ikke påvirker søketiden, så lenge associativity er uforandret. K8 har jo samme tilgangstider på alle L2-størrelser, noe som tyder på det samme. Men jeg ser riktignok ikke helt bort ifra at dette kunne vært annerledes hvis f.eks. Sempron var ment for å ha 256 kB L2 fra bunnen av. Altså istedenfor at de større, delvis defekte cachene til en viss grad blir deaktiverte - når hele mengden i utgangspunktet var ment å være aktiv.

 

Jeg har lurt på om en økning av linjestørrelsen fra 64 til 128 byte, eventuelt en økning i L1-associativity fra 2-way til 4-way kunne gitt en positiv effekt. Tanken bak det er naturlig nok å redusere conflict-rate. Etter overgangen til 64-bits vil det jo bli flere lange instruksjoner/data, og det vil følgelig bli "trangere om plassen".

 

Hvis det er slik at en liten "L0" kunne implementeres til lavere tilgangstid, kan du jo være inne på noe. Om jeg tolker deg rett angående plassering av oversetter og lagring av ferdigbehandlede instruksjoner, måtte vel den ekstra cachen vært inkluderende i forhold til L1. Slik at instruksjonene ikke måtte oversettes tilbake igjen ved evictions (det er ihvertfall hva jeg ser for meg).

 

En annen ting: Kunne det vært en idé å innføre et nytt L3 cache-nivå i form av en "ekstern" DRAM-brikke på Operon-serien. F.eks implementert som en MCM (Multi Chip Module) med en spesialdesignet DRAM-brikke under lokket på CPUen. F.eks en med 1024bit bussbredde og et rask DDR3-minne på f.eks 16-32 MiB. ?

Hvordan stiller egentlig den raskeste DRAMen seg i forhold til SRAM?

 

Jeg regner ihvertfall med at selv den beste DRAM vil være mye tregere, men det er jo ikke dermed sagt at en slik buffer ikke kunne hatt noe for seg. Hele minnehierarkiet kan jo ses på som en "pyramide" hvor de øverste nivåene er de minste og raskeste, og hvor ytelsen reduseres/størrelsen økes når det legges til flere nivåer. Så lenge hvert nivå er et fornuftig kompromiss mellom ytelse og størrelse kan det jo være hensiktsmessig å plusse på med flere (ihvertfall inntil et visst punkt). Størrelsen du foreslår vil nok være en fornuftig mellomting mellom L2 og RAM. Derfor kunne det nok gi ytelsesgevinst, selv om den naturligvis ville vært tregere enn den "ekte" cachen. Hvorvidt dette ville la seg gjennomføre av hensyn til areal og økonomi har jeg ingen anelse om - det regner jeg med at du allerede har fundert litt over... Men ytelsesmessig vil jeg som nevnt ikke utelukke at det kunne ha noe for seg.

 

 

Uansett vil vel det meste vi diskuterer her kreve et omfattende redesign av arkitekturene, slik at det ikke bare kan "klaskes på" det eksisterende designet...

 

Det var ihvertfall fint å få litt å tygge på

[panzerwolf]

Dæven, så mye jeg lærte her... Takk Bob Ibsen! En ting er at du har mye kunnskap om emnet, men du klarer i tillegg å formidle det på en god og lettforståelig måte, og det er vel så viktig som selve kunnskapen

[Bob Ibsen]

Takk for det Vel, det kjipe er at jo mer jeg leser, jo lengre blir lista over de tingene jeg må innse at jeg ikke kan... At noe kan være så sammensatt og komplekst er nesten skummelt. Enda er jo cache bare en liten del av CPU-arkitektur generelt...

[el-asso]

Størrelse er en ting, men AMDs lave associativity gir jo en fordel med tanke på antallet tags som må sammenlignes per søk. AMD oppgir L1-latency til tre sykluser, som er i samsvar med målinger jeg har sett. Lav associativity i kombinasjon med den store mengden gir naturlig nok mange frames/sets, men jeg har ikke trodd at dette påvirker søketiden. John Stokes på Ars får det heller ikke til å høres slik ut:

 

Furthermore, since all the sets consist of exactly four blocks, no matter how big the cache gets we'll only ever have to search through four frames (or one set) to find any given block. This means that as the cache gets larger and the number of sets it can accommodate increases, the more efficient the tag searches get. Think about it. In a cache with three sets, only 1/3 of the cache (or one set) needs to be searched for a given block. In a cache with four sets, only 1/4 of the cache is searched. In a cache with 100, four-block sets, only 1/100 of the cache needs to be searched. So the relative search efficiency scales with the cache size.

Hva han mener er altså at økt størrelse og dermed flere frames i seg selv ikke påvirker søketiden, så lenge associativity er uforandret.

Selv om det ikke er det som sies her så er det viktig å ha klart for seg at en økning av antall frames innenfor en gitt cache-størrelse øker sjansene for "conflict" (bare i tilfellet noen trodde det var en enkel løsning å øke antall frames).

 

Det med antall blocks pr. frame blir jo hele tiden en avveining som konstruktørene må ta, og noen fasit finnes neppe siden det som er mest gunstig varier i forhold til programmene som kjøres. Det blir mer spørsmål om å finne den gyldne middelvei (i forhold til resten av arkitekturen.)

 

I følge en eldre artikkel av "Hannibal" jeg leste var vel 4 - 8-way ass. det han anså som optimalt (tar forbehold om at jeg husker feil).

 

Simen1: Skjønner ikke helt hva behovet for ett nytt hurtigere L0 cachenivå skal være, L1 er da mer en raskt nok?

Endret 23. september 2005 av el-asso

[Bob Ibsen]

Selv om det ikke er det som sies her så er det viktig å ha klart for seg at en økning av antall frames innenfor en gitt cache-størrelse øker sjansene for "conflict" (bare i tilfellet noen trodde det var en enkel løsning å øke antall  frames).

Klart, så lenge størrelsen er konstant, vil jo flere frames uunngåelig føre til redusert associativity, som gir lavere tilgangstid, men høyere conflict-rate. Har du forresten noe å tilføye angående søketid? Er det flere ting som må tas i betraktning?

 

I følge en eldre artikkel av "Hannibal" jeg leste var vel 4 - 8-way ass. det han anså som optimalt (tar forbehold om at jeg husker feil).

Det kommer fra samme artikkel, men her tipper jeg at han mente om begge nivåene skulle ha noenlunde lik associativity - dvs metoden som Intel har for vane å bruke. For eksempel har Prescott og Dothan 8-way over "hele fjøla". AMDs løsning er jo temmelig annerledes i og med at L1 er 2-way, som er meget lavt, og L2 bruker 16-way, som er høyt.

 

In general, it turns out that when you factor in current technological conditions (i.e. the speed of tag RAM, the range of sizes that most caches fall into, etc.) some level of associativity less than or equal to eight-way turn out to be optimal for most caches. Any more than eight-way associativity and the cache's latency is increased so much that the decrease in miss rate isn't worth it. Any less than two-way associativity and the number of collisions often increase the miss rate to the point that the decrease in latency isn't worth it.

Graf fra wikipedia:

 

Simen1: Skjønner ikke helt hva behovet for ett nytt hurtigere L0 cachenivå skal være,  L1 er da mer en raskt nok?

Tenkte egentlig på det samme, og mine idéer om økt linjestørrelse, eventuelt økt associativity går jo litt i motsatt retning. At L1-latency er på tre sykluser har jeg lest så mange steder at jeg nærmest regner det som "opplest og vedtatt"

[Simen1]

Bob Ibsen: Tror du det hadde gitt noe mening om AMD innførte et nytt cachenivå mellom L1 og kjernen? Jeg tenker da at dagens L1 er ganske treg fordi den er så stor. Kunne det gjort seg med f.eks en liten (8 kiB?) inclusive instruksjonscache med ferdigdekode instruksjoner?

Ferdigkodede instruksjoner - mener du et lager for microOps, dvs noe à la Intels trace cache, bare at oversetteren skulle vært mellom L1 og vår forestilte "L0"?

 

Hvis det er slik at en liten "L0" kunne implementeres til lavere tilgangstid, kan du jo være inne på noe. Om jeg tolker deg rett angående plassering av oversetter og lagring av ferdigbehandlede instruksjoner, måtte vel den ekstra cachen vært inkluderende i forhold til L1. Slik at instruksjonene ikke måtte oversettes tilbake igjen ved evictions (det er ihvertfall hva jeg ser for meg).

Du tolker meg riktig angående plasseringen av oversetteren og at cachen er ment som inclusive i forhold til L1. Altså at L1 ivaretar de udekodede instruksjonene, mens "L0" ivaretar de samme instruksjonene i dekodet tilstand. Tanken er som du sier å senke aksesstiden ytligere. F.eks ned fra 3 til 1 syklus pluss at man slipper dekoding før instruksjonene når lengre ned i pipelinen, noe som sikkert vil spare ennå et par-tre sykluser.

 

Simen1: Skjønner ikke helt hva behovet for ett nytt hurtigere L0 cachenivå skal være,  L1 er da mer en raskt nok?

Jeg vet ikke om den er raskt nok, men så bare på muligheten for en ennå raskere cache. Siden hastigheten på cache synker med økende størrelse og K8 sin L1 cache er veldig stor (sammenlignet med P4) så antok jeg at den også var relativt treg i forhold til P4 sin L1. Dermed så jeg et behov for et mellomnivå. Kanskje et økende behov med 64bit OS og programvare siden 64bit kode tar rundt 20% ekstra plass og lagringsplassen i registrene "halveres" ved bruk av 64bit kode. (Mulig jeg tar feil på det siste her, men jeg slenger det ut likevel).

Endret 23. september 2005 av Simen1

[Simen1]

En annen ting: Kunne det vært en idé å innføre et nytt L3 cache-nivå i form av en "ekstern" DRAM-brikke på Operon-serien. F.eks implementert som en MCM (Multi Chip Module) med en spesialdesignet DRAM-brikke under lokket på CPUen. F.eks en med 1024bit bussbredde og et rask DDR3-minne på f.eks 16-32 MiB. ?

Hvordan stiller egentlig den raskeste DRAMen seg i forhold til SRAM?

 

Jeg regner ihvertfall med at selv den beste DRAM vil være mye tregere, men det er jo ikke dermed sagt at en slik buffer ikke kunne hatt noe for seg. Hele minnehierarkiet kan jo ses på som en "pyramide" hvor de øverste nivåene er de minste og raskeste, og hvor ytelsen reduseres/størrelsen økes når det legges til flere nivåer. Så lenge hvert nivå er et fornuftig kompromiss mellom ytelse og størrelse kan det jo være hensiktsmessig å plusse på med flere (ihvertfall inntil et visst punkt). Størrelsen du foreslår vil nok være en fornuftig mellomting mellom L2 og RAM. Derfor kunne det nok gi ytelsesgevinst, selv om den naturligvis ville vært tregere enn den "ekte" cachen. Hvorvidt dette ville la seg gjennomføre av hensyn til areal og økonomi har jeg ingen anelse om - det regner jeg med at du allerede har fundert litt over... Men ytelsesmessig vil jeg som nevnt ikke utelukke at det kunne ha noe for seg.

 

Uansett vil vel det meste vi diskuterer her kreve et omfattende redesign av arkitekturene, slik at det ikke bare kan "klaskes på" det eksisterende designet...

 

Det var ihvertfall fint å få litt å tygge på

DRAM har mye lengre aksesstid enn SRAM og mye lavere klokkehastigheter, men det har en del fordeler jeg tenkte kunne være nyttig: Mye lavere effektbehov = mindre varme. Mye færre transistorer per celle gir mye høyere lagringstetthet. AMD's L2 cache (SRAM) har en kapasitet på anslagsvis 2 MiB per 100mm^2, mens en like stor DRAM-brikke har en kapasitet på anslagsvis 16-32 MiB. Angående hastighet så er aksesstiden til RAM ganske mange CPU-klokkesykluser (~60?). En DRAM-brikke plassert under lokket på CPU'en vil kunne benytte helt andre og mye raskere DRAM-brikker enn vanlig systemram. Se f.eks hvor raske GDDR-rambrikker til grafikkort er. Hvis vi kunne fått en sånn brikke som L3-cache så ville det gitt en stor L3 cache som er mye raskere enn ram på både aksesstid og båndbredde. Hvor mye har egentlig båndbredde til denne tenkte L3 cachen å si på ytelsen?

 

Tanken er at mengden cache har mye å si for en rekke tjener-applikasjoner. Tradisjonellt har dermed CPU'er til tjenere fått store mengder cache og dette har blitt brukt som et stort salgsargument. Derfor tenkte jeg at 16-32 MiB L3 ville vært et stort pluss for Operon-serien.

 

Hvis vi tenker oss tilbake til slutten av 90-tallet så var det populært med ekstern L2 cahce i form av en egen SRAM-modul på hovedkortet (Pentium MMX, K6-2, K6-III). Ett av hovedproblemene her var at det ga lang aksesstid til L2 cachen på grunn av lang fysisk avstand og på grunn av lav båndbredde på grunn av dårlig signalintegritet i sokkelen og hovedkortet, samt en sterkt begrenset bussbredde. Litt senere på 90-tallet ble det populært med L2 cache som ekstern SRAM-brikke på CPU-modulen (Pentium III "katmai" og Athlon "K7" og "K75"). Denne cachen var raskere enn før på grunn av bedret signalintegritet og egen cache-buss. Etter denne epoken ble L2 cache implementert på selve CPU'en. Det at CPU og L2 måtte dele die betød i starten fysisk store brikker til tross for redusert størrelse på L2 cache. Til tross for redusert L2-størrelse så ble det raskere på grunn av ennå tettere kobling mellom CPU og L2. Fysisk nærhet er ikke bare viktig for mennesker, men også i forholdet mellom CPU og L2.

 

SRAM og typiske CPU-kjerner bruker så vidt jeg vet samme type wafere og samme type og mengde doping så de kan enkelt produseres sammen, men DRAM bruker vistnok andre dopingteknikker for å øke kapaistansen. Dette gjør det vanskelig å implementere DRAM på samme die som CPUen. Dette er bakgrunnen for at jeg foreslo en MCM (Multi Chip Module). MCM ser jeg på som det fysisk mest nærme man kan plassere CPU og L3. Dette vil ikke øke antall pinner på CPUen samtidig som man kan ha en ganske bred buss. L3 kan være så fysisk liten at den passer under lokket ("varmesprederen") på eksisterende Opteroner, selv de med dobbeltkjerne. f.eks en brikke med 16-32 MiB = ~100mm^2.

 

Økonomisk sett så koster ikke GDDR3 på med effektiv hastighet på 1,6GHz spesielt mye. Det er mye billigere enn f.eks like mye SRAM. Jeg ser for meg at det er mulig å bruke DDR3-ram på minst 1,6GHz med f.eks 512bit minnebuss på en brikke fremfor eksisterende GDDR3 på 1,6GHz og 32bit bussbredde per brikke. 512bit ser jeg på som realistisk siden brikkene ligger fysisk så nært hverandre og det ikke trengs hverken CPUpinner, eller minnesokler som takler så mange pinner. Det eneste vi trenger et en minnebrikke med svært mange BGA-punkter og like mange ekstra BGA-punkter under CPUen. Hvis 512bit ikke er å ta for hardt i så vil det bety en båndbredde på utrolige ca 105 GB/s L3 cache. Aksesstid på DDR3/GDDR3 vet jeg ikke men antar det vil være betydelig kortere enn systemram. Altså voldsomt mye mer enn systemram på 6,4 GB/s (dobbeltkanal PC3200).

 

I forhold til L2 bør nok L3 være exclusive, men i forhold til RAM så vet jeg ikke helt hva som gir mest mening av exclusive eller inclusive. Kanskje NUMA-støtte mellom L3 og ram også kan gi mening.

 

Jepp, det er morsomt å fundere på litt hypoteser

Endret 23. september 2005 av Simen1

[ATI vs GeForce]

Så AMD San Diego 2,4ghz 4000+ burde være et røverkjøp etter alt jeg har lest? Har tenkt å kjøpe den...

[Simen1]

Røverkjøp? Det er ikke sånn jeg leser resultatet.

Athlon64 "Venice" 3800+ med 2,4GHz koster fra 2745 kr

Athlon64 "San diego" 4000+ med 2,4GHz koster fra 3189 kr

 

Den eneste forskjellen mellom disse er mengden L2 cache og 444 kr.

I følge testen så er det bare små forskjeller i ytelse mellom disse. Anslagsvis 3-5% etter mitt øyemål. Prisforskjellen er derimot rundt 16%. Den siste lille ytelsen koster altså mye mer enn ytelsen på "Venice"-utgaven.

 

En annen ting er at kjøpet av "San Diego" er ennå dårligere om du har tenkt til å overklokke. Dvs. den billigste "venice" koster bare drøye 1200kr, mens den billigste "San Diego" koster fra ca 2300kr. Altså ca dobbel pris (1100kr mer). Disse to klokker omentrent like langt med lik kjøling, mens den dyre yter bare en liten smule bedre. Men betaler altså 1100kr (dobbel pris) for noe som er ganske så umerkbart.

 

I stedet for å bruke 1100kr på noe så umerkbart vil jeg anbefale å bruke disse pengene på mye mer merkbare ting. F.eks oppgradere systemdisken til Raptor 74GB eller velge et skjermkort som er 1100kr dyrere enn du hadde planlagt først.

[ATI vs GeForce]

Har et XFX geforce 6600GT AGP. Hadde tenkt å kombinere 4000+ San Diego cpu`n med dette hovedkortet:

 

http://www.mpx.no/aspx/prdinfo.aspx?plid=54611

[Bob Ibsen]

Simen1: Skjønner ikke helt hva behovet for ett nytt hurtigere L0 cachenivå skal være,  L1 er da mer en raskt nok?

Jeg vet ikke om den er raskt nok, men så bare på muligheten for en ennå raskere cache. Siden hastigheten på cache synker med økende størrelse (...)

Kan du utdype hvordan størrelsen isolert sett reduserer hastigheten?

 

Kanskje et økende behov med 64bit OS og programvare siden 64bit kode tar rundt 20% ekstra plass og lagringsplassen i registrene "halveres" ved bruk av 64bit kode. (Mulig jeg tar feil på det siste her, men jeg slenger det ut likevel).

64-bits OS og kode vil jo aktivere 64-bit "long mode" slik at GPRs fulle bredde kan utnyttes. Jeg ser ikke hvordan det skal bli verre enn hva som er ståa for de fleste idag, hvor man ikke får utnyttet hele bredden (i Legacy Mode). Både instruksjonslengde og registerlengde vil jo "blåses opp" like mye, og følgelig gå opp i opp?

[el-asso]

Du tolker meg riktig angående plasseringen av oversetteren og at cachen er ment som inclusive i forhold til L1. Altså at L1 ivaretar de udekodede instruksjonene, mens "L0" ivaretar de samme instruksjonene i dekodet tilstand. Tanken er som du sier å senke aksesstiden ytligere. F.eks ned fra 3 til 1 syklus pluss at man slipper dekoding før instruksjonene når lengre ned i pipelinen, noe som sikkert vil spare ennå et par-tre sykluser.

 

Simen1: Skjønner ikke helt hva behovet for ett nytt hurtigere L0 cachenivå skal være,  L1 er da mer en raskt nok?

Jeg vet ikke om den er raskt nok, men så bare på muligheten for en ennå raskere cache. Siden hastigheten på cache synker med økende størrelse og K8 sin L1 cache er veldig stor (sammenlignet med P4) så antok jeg at den også var relativt treg i forhold til P4 sin L1. Dermed så jeg et behov for et mellomnivå.

Cache følger CPU klokken og RAM følger FSB/Minnebuss-divideren. Den forsinkelsen som måtte være i cache L1 skyldes vel først og fremst graden av associativity og følgelig antall "tags" som må søkes gjennom. I motsetning til for RAM (som befinner seg lengre vekk og har en annen hastighet mot CPU) er forsinkelse til Cache som følge av systemtreghet vel å regne som minimal. Intel har jo også lagt inn to "drive" trinn i P4 pipelinen for å kompensere at signalene on-die ikke rekker raskt nok fram. "Problemet" med forsinkelse er så vidt jeg kan se ikke signalhastigheten on-die, men mer måten cache operer på.

Intels Trace cache er jo ett eksempel på det du sier om L0 for dekodede instruksjoner. Som deg tror jeg også det er behov for/vil komme endringer. Kanskje bare to Cache nivåer, étt for ukodede og ett for dekodede og taggede ops uten behov for frames og problemstillingen rundt associativity?

 

Mulig det er Branch Units og styret rundt branch prediction som er det største hinderet for en mer effektiv Cache, men en kan også si det på en annen måte; hadde det ikke vært for Cache hadde heller ikke Branch Prediction vært mulig.

Problemet kan unngås, men da snakker vi om en helt annen arkitektur som er behørlig diskutert i andre tråder.

 

 

Bob Ibsen: Glemte å si det sist gang, men dette er den beste tråden på

lenge

 

Edit: Rettet HT buss i 1.setning til minnebussdivider

Endret 25. september 2005 av el-asso

[Bob Ibsen]

Bob Ibsen:  Glemte å si det sist gang,  men dette er den beste tråden på lenge 

Takk! Må si jeg er meget fornøyd med retningen denne tråden har tatt - dette er virkelig mat for mons! Vi har jo beveget oss milevis utenfor de nokså stramme rammebetingelsene til startinnlegget, hvor poenget i hovedsak var å få frem de grunnleggende forskjellene mellom inkluderende og ekskluderende relasjoner. Men det er jo ikke mindre spennende å bygge videre på øvrige aspekter av den grunn

 

Angående mine tanker om å øke linjestørrelsen tror jeg ikke lenger det ville være noen god idé. Forutsatt god spatial locality kunne det gitt visse fordeler, ettersom større working sets hadde fått plass i samme linje, og det i større grad ville gitt ”automatisk” prefetching. Men en dobling av linjestørrelsen innenfor samme mengde og associativity ville halvert antallet frames, noe som kan øke conflict rate. Dette fordi minneadressene ville fått færre ”forgreninger” å fordele seg på. Større linjer ville også gitt økt pollution, og dermed ofret mer plass og båndbredde på å cache unyttige data. Cachehåndteringen ville altså bli mindre nyansert, noe som er relevant fordi spatial locality varierer veldig fra en applikasjon til en annen.

 

En dobling av antallet frames, når linjestørrelse og mengde er uforandret, ville gitt halvert associativity – og dermed økt conflict rate (som tidligere nevnt). Denne ulempen ville nok vært mer dramatisk i dette scenariet enn ved en dobling av linjestørrelsen.

 

Her er det visst noen sirkelreferanser å ta hensyn til...