Gå til innhold

AMD BARCELONA INFO


Anbefalte innlegg

Videoannonse
Annonse
Utifra den atikkelen skal barcelona få fire 64 bit ddr 2 (og 3) kontrollere. mot K8 sin enkle 128 bit skulle det bety at vi får qvad ddr (i motsetning til dural ddr) og at det blir mer fleksiblelt med tanke på minne.

8053789[/snapback]

Jeg tolker det slik at de fremdeles vil ha to datakanaler, bare fordelt utover to uavhengige kontrollere (som har hver sin 64-bits databuss):
The K8 core (Socket-940/939/AM2) featured a single memory controller that was 128-bits wide, but in Barcelona AMD has split up the DRAM controller into two separate 64-bit controllers. Each controller can be operated independently and thus you get some improvements in efficiency, especially when dealing with quad core implementations where the individual cores working on independent threads all have their own memory access patterns.
Dette høres ut som en meget interessant løsning, da det vil gi bedre muligheter til å kamuflere forsinkelser. I teorien vil jo minnet alltid kunne leses fra, og dette vil også gi gode muligheter for finplukking av data, uten at utnyttelsen reduseres av kommando-kollisjoner, som kan være tilfellet pr idag.

 

 

Forøvrig har jeg noen kommentarer til det som skrives om minnekontrollerne:

The K8's memory controller made some allowances for preferring reads over writes since they take less time, but in Barcelona the memory controller is far more intelligent.
Hjelpeløs forklaring. At K8 har muligheter til å prioritere leseoperasjoner er greit nok, men å begrunne det med at lesing tar kortere tid er mildt sagt latterlig. Alle forespørslene må jo tas hånd om uansett hvor lang tid de måtte ta, og det er forøvrig heller ikke noen automatikk i at skrive-sekvenser tar lengre tid.

 

Motivene for å utsette skriveoperasjoner når kontrolleren er midt i en lese-sekvens, er a) å unngå hyppige turnarounds (hvor bussen går på "tomgang"), og b) at leseforsinkelsen har direkte konsekvenser for program-eksekveringen (i motsetning til skrive-operasjoner, som i prinsippet er "fire & forget" for prosessorens del). I skrive-sekvenser spiller det heller ikke noen rolle hvilke data som skrives først, men bare hvor lang tid det tar fra A til Å. Altså hvor lang tid det tar å fullføre en gitt intervall, slik at kontrolleren igjen kan begynne å lese fra minnet.

 

Now, instead of executing writes as soon as they show up, writes are stored in a buffer and once the buffer reaches a preset threshold the controller bursts the writes sequentially. What this avoids is the costly read/write switch penalty, helping improve bandwidth efficiency and reduce latency.
Jeg har mine sterke tvil til at K8 konsekvent skifter over fra lesing til skriving så snart det dukker opp en skrive-forespørsel. Det finnes to innstillinger som påvirker måten køene organiseres på: Bypass Max og Read/Write Queue Bypass Count.

 

Sistenevnte omtales noen ganger også som Read Around Write Queue Bypass, som tydelig insinuerer at kontrolleren midlertidig "runder" skrive-forespørsler. Jeg regner sterkt med at denne parameteren regulerer hvor mange leseoperasjoner som kan håndteres i slengen - etter at en skrive-kommando mottas. Dvs at kontrolleren kan tillate inntil 16 leseoperasjoner før den må ta hensyn til en skrive-forespørsel. Det kan allikevel tenkes at K8 ikke kan bufre mer enn en skrive-kommando om gangen, slik at trafikken må skifte retning så snart det eventuelt kommer skrivekommando nummer to. Men jeg er altså temmelig sikker på at de tar feil i sin påstand om at K8 må foreta et momentant skifte når en skrivekommando mottas i køen.

 

Men når det er sagt har jeg ingen som helst grunn til å tvile på at AMD nå utbedrer dette området, og synes de annonserte inngrepene virker lovende.

Endret av Quintero
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å
×
×
  • Opprett ny...