"Nehalem"-brikkesett på tapetet

[Simen1]

Tenker du at det som normalt behandles som 64-bits enheter (kolonner) skulle omorganiseres og leses i serie bestående av 4 overføringer à 16 bits?

På hver av de 4 kanalene, ja.

 

De fire kanalene vil til sammen danne 64 fysiske sett med dataledere men omorganiseringen vil gjøre det mulig å aksessere 4 uavhengige steder i minnet samtidig. Noe jeg jeg i farta tenkte kunne være lurt for å gi en bedre loaded latency i systemer med en flerkjerneprosessor. Men jeg innser at jeg er på dypt vann her. Jeg har ikke brukt mye tid på å tenke gjennom løsningen.

[Quintero]

Ingenting galt i litt høyttenkning

 

Men jeg ser noen potensielle problemer bak en slik løsning, litt avhengig av hvordan selve kontrolleren skulle vært..

 

 

Hvis planen er at hver kanal skulle hatt en egen kontroller, så er det neppe gunstig. Både modulen og kontrollerene måtte hatt en bråte med adressepinner, siden det ville handlet om uavhengige kommandoer. Det ville nok også hevet kompleksitetsnivået til kontrollerene urimelig mye.

 

 

Men for å kunne adressere *uavhengige* data fra forskjellige kanaler, uten å legge til flere kontrollere, så kunne ikke kanalene ha blitt aksessert i paralell. Hvis alle chipene (som altså tilsammen utgjør fire kanaler) skulle respondere på en kommando samtidig, så måtte de ha utført nøyaktig samme operasjon. Og det ville vel være drøyt å gamble på at forskjellige applikasjoner ba om hver sine data, som tilfeldigvis måtte ligge under samme adresse

 

Lockstep-modus er som kjent ikke noen forutsetning for at flere kanaler skal ha noe for seg. For AMD har det vært et naturlig valg siden de lanserte socket 939, fordi minnet der har en dedikert buss som ikke behøver å dele båndbredde med trafikken til/fra brikkesettet (i motsetning til FSB-prinsippet). Intel har samtidig benyttet kontrollere som i varierende grad veksler mellom kanalene, og bare leser to kanaler i bredd under spesielle forutsetninger. Når urelaterte data skal hentes, så vil altså en Intel-kontroller sende to uavhengige forespørsler, men aldri på samme syklus.

 

En ting er at det ville har krevd ganske mange ekstra pinner, selv med bare en kontroller. Når det gjelder adressering, så kunne både chipenes, modulenes og kontrollerens grensesnitt vært temmelig uforandret i forhold til normen. Det ville bare ha krevdes ekstra Chip Select-pinner til å styre hver kommando til de riktige chipene. Men siden kanalene til enhver tid ville befunnet seg på ulike stadier i en lese/skrive-prosess, så ville det være nødvendig med ekstra logikk (i kontroller) og flere pinner (på modul og kontroller) til å styre terminerings-verdiene. Dette ville nok også kunne redusere fleksibiliteten og effektiviteten mtp skifte i trafikkens retning.

 

Når det gjelder poenget om bedre dataorganisering, så spørs det om foreslåtte eksempel ville gitt fordeler over metodene som allerede er i bruk, som jeg regner som smarte og velprøvde strategier. Alt minne er delt inn i uavhengige banker, som ved god organisering kan bidra til å unngå forsinkelser, i tillegg til å kamuflere de operasjonene som må gjennomføres. Applikasjoner kan tildeles spesielle områder i minnet, og kontrolleren "ser" alltid et stykke fremover. På den måten kan nye områder forberedes på fremtidige operasjoner mens databussen likevel er opptatt.

 

 

Kolonnebredden på 64 bits er jo velprøvd, og virker så langt jeg kan bedømme å være rimelig overveid og tilpasset i forhold til resten av systemet. En fordel ved å ta "alt i ett" (1x64 bits istedenfor 4x16 bits), er at det tar kortere tid før prosessoren mottar data som den kan jobbe på. Det er ikke uten grunn at minnekontrollere kan stokke om på rekkefølgen som kolonnene overføres i (Burst Ordering). Uansett hvilken rekkefølge kolonnene har i radene, kan kolonnen som inneholder Critical Word prioriteres. Isolert sett ville ikke dette vært like effektivt om dataene var ytterligere spilittet. Nå kan man kanskje se for seg at den gjennomsnittlige forsinkelsen til forskjellige applikasjoner kunne blitt lavere, siden hver kanal kunne overføre forskjellige data. Men da må man huske på at RAM slik vi kjenner det har gode muligheter til å "hoppe" i adresseområdet, og her er også multibank-arkitektur et sentralt tema. Selv ikke DDR3 er nødt til å overføre mer enn fire kolonner pr interne prefetching, før det kan utføres et sømløst skifte til andre områder (under visse forutsetninger). Å overføre 4x64 bits ville jo ikke tatt noe lengre tid enn 4x16 bits, men å tilpasse neste operasjon slik at den overlapper ville nok blitt vanskeligere i et system med flere kanaler (pr kontroller) fordi adressebussen vanligvis ville vært mer belastet. Og nå kommer jo K10 med en kontroller pr datakanal, som ytterligere forbedrer effektiviteten til det "vante" systemet.

 

Så selv om en oppstykking av minnebussen ville gitt større frihet på noen områder, tror jeg ikke at en slik løsning ville være særlig gunstig fra et helhetlig perspektiv.

Endret 7. november 2007 av Quintero

[Simen1]

Takk for oppklaringen. Det var som jeg tenkte, ting jeg ikke hadde tenkt på.