Intel viser Xeon "Tulsa"

[int20h]

Intel har i samarbeid med Dell denne uken demonstrert den kommende "Tulsa"-prosessoren, som skal hamle opp med Opteron.

Les mer

[JohndoeMAKT]

Flippmeg, jeg satt juice i halsen da jeg leste dette:

1,3 milliarder transistorer

Og her sitter jeg med puslete Prestonia prosessorer med bare 55 millioner transistorer.

[Simen1]

Flisespikking:

ekxempelvis

 

JohndoeMAKT: Det høye antall transistorer skyldes nok den store cachen. Jeg regner med at ca 90-95% av transistorene tilhører cachesystemet.

 

Ellers så kunne jeg nok satt frokosten i halsen når jeg leste 150W, men heldigvis er jeg ferdig med frokosten for i dag Cache bruker normalt veldig lite effekt i forhold til det totale effektforbruket på brikken så jeg lurer litt på hvorfor tallet blir så høyt på bare 3,4GHz. De har jo laget dobbeltkjernede netburstprosessorer på den hastigheten, uten L3, med 65nm før med langt lavere effektforbruk (95W om jeg ikke husker feil). Intel har tradisjonellt også vært svært flinke til å lage effektgjerrig og kompakt cache så dette hoppet virker mystisk.

[kindings]

Flisespikking:

ekxempelvis

 

JohndoeMAKT: Det høye antall transistorer skyldes nok den store cachen. Jeg regner med at ca 90-95% av transistorene tilhører cachesystemet.

 

Ellers så kunne jeg nok satt frokosten i halsen når jeg leste 150W, men heldigvis er jeg ferdig med frokosten for i dag Cache bruker normalt veldig lite effekt i forhold til det totale effektforbruket på brikken så jeg lurer litt på hvorfor tallet blir så høyt på bare 3,4GHz. De har jo laget dobbeltkjernede netburstprosessorer på den hastigheten, uten L3, med 65nm før med langt lavere effektforbruk (95W om jeg ikke husker feil). Intel har tradisjonellt også vært svært flinke til å lage effektgjerrig og kompakt cache så dette hoppet virker mystisk.

6690924[/snapback]

Det kommer vel 2 utgaver, en med 95W og en med 150W. Nå er ikke effektforbruket det helt store problemet dersom kjølingen er god nok. Ble vel mer overrasket da jeg så AMD rulle ut sokkel F og hadde en versjon med 120W, de har tross alt gått ganske langt med å gjøre narr av Intels Netburst CPUer og det høye effektforbruket. Dog virker det som dette er en gjenganger når ett CPU arkitektur begynner å gå mot slutten av livssyklusen(kanskje en selvfølge?), jeg ser selv på denne Intel CPUen som det nårværende Netburst arkitekturets siste pust i bakken Intel prøver nok bare å skvise siste rest ut av dette markedet før de går over til Core..

[efikkan]

Netburst skal nok melkes mest mulig. (I likhet med K8 som trenger en arvtager) Jeg ville nok ikke gått for Netburst i dag med mindre det er utrolig billig.

[Reeve]

1.3 Mrd transistorer er jo bare ekstremt men hvar det mye å si på ytelse, når det er så mye? og hva er forskjellen på L2 og L3 cache?

[Simen1]

1.3 Mrd transistorer er jo bare ekstremt men hvar det mye å si på ytelse, når det er så mye?

Det er ett av spenningsmomentene hvilke applikasjoner som yter bedre og hvor mye bedre på grunn av L3 cachen.

 

og hva er forskjellen på L2 og L3 cache?

6692917[/snapback]

Det er bare nok et nivå:

- L1 har ekstremt lav latency men er til gjengjeld ekstremt liten

- L2 har lav latency men er til gjengjeld liten

- L3 har middels latency men er til gjengjeld middels stor

- Ram har treg latency men er til gjengjeld veldig stor

- Harddisk har ekstremt treg latency men er til gjengjeld ekstremt stor

 

Minnehireriarkiet er altså i stor grad styrt av mengde og latency. Jo lavere latency jo mer koster det per byte og jo større er de tekniske utfordringene med å lage stor lagringsplass. Et godt balansert minnehireriarki har passe store hopp i latency og mengde for hvert trinn.

[Vindstille]

Det er bare nok et nivå:

- L1 har ekstremt lav latency men er til gjengjeld ekstremt liten

- L2 har lav latency men er til gjengjeld liten

- L3 har middels latency men er til gjengjeld middels stor

- Ram har treg latency men er til gjengjeld veldig stor

- Harddisk har ekstremt treg latency men er til gjengjeld ekstremt stor

6694167[/snapback]

Kan du forklare litt hva latency er?

Vet sånn halveis hva det er, men fint med litt mer kunnskap.

[Simen1]

Latency er på godt norsk ventetid. F.eks når du skrur på dusjen om mårran så bør man ikke stille seg under strålen før etter en liten stund. Det vannet som har stått i rørene mellom varmtvannstanken og dusjen hele natta og blitt kjølig trenger litt tid på å tømmes ut før det varme vannet når frem til blanderen og ut av dusjen. Ventetiden er dusjens latency.

 

En moderne prosessor arbeider på 2-3GHz og gjør altså unna 2-3 klokkesykluser per nanosekund (milliarddels sekund). Samtidig gjør den unna ca 2 instruksjoner på hver av disse syklusene. I teorien er det ønskelig at prosessoren får en jevn strøm av instruksjoner og data. Men veldig ofte er input til enkelte instruksjoner avhengig av resultater fra andre operasjoner. Disse ligger ikke nødvendigvis i rekkefølge så ofte finnes ikke dataene som trengs i registeret i prosessoren. Det gjør at den må hente data fra et eller annet lager som er litt større, dvs. fra L1 cahce. For å hente noe derfra så er det ventetid/latency. Den er ofte på 2 klokkesykluser. Eldre prosessorer stopper helt opp å jobbe og venter de to klokkesyklusene før den får data nok til å jobbe videre. Moderne prosessorer (Siden den orginale Pentium) stabler bare litt om på instruksjonene i sånne tilfeller og ser om den kan gjøre andre og uavhengige instruksjoner i mellomtiden. Det går som regel ganske greit. La oss si prosessoren klarer i snitt 2 instruksjoner i ventetiden i stedet for de teoretiske og normale 4-6 instruksjonene. Da får den i hvertfall gjort litt. Nyere prosessorer enn Pentium er ennå flinkere til å stable om instruksjoner for å fylle ventetiden med noe fornuftig å gjøre. Men 2 sykluser er jo som nevnt lengre opp ekstremt raskt. Det med ventetid begynner først å bli interresant når det kommer til L2 cache. Denne kan bruke mellom 6 og 12 sykluser på å hente ut data. Da kan prosessoren bli stående å vente utolmodig eller pusle litt med forefallende arbeid i mellomtiden før den får dataene sine og kommer i gang med jobben. Noen ganger (ca 1-4% av gangene) finner den ikke det den vil ha i L2 cahcen heller (cache miss). Da må den virkelig streve med å finne noe annet å gjøre for det å hente noe fra L3 cahcen kan ta hele 10-20 klokkesykluser. For å dra inn dusjeksemplet og ventetida igjen så blir det litt som når den lille varmtvannstanken (L1) som henger på dusjen er tom, så bruker den varmtvann fra den litt større tanken (L2) i naborommet, og deretter fra den ennå større tanken (L3) i naboleiligheta. Noen ganger finner den ikke det den skal ha i L3 heller og da blir neste nivå hele 40-100 klokkesykluser unna før den får hentet noe fra ram. Det blir en hel del venting dersom det er mye kritiske data som skal hentes frem fra et stort minneområde. Selv om L2-miss bare skjer i 1 av 1000 klokkesykluser og prosessoren må vente i 100 sykluser uten noe å gjøre så betyr latencyen til minnet at det i teorien er 10% bedre ytelse å hente på lå fjerne all minnelatencyen. Det går selvsagt ikke, men en reduksjon vil hjelpe litt på ytelsen.

 

Militæret er jo fullt av "ventetjenester". F.eks at man ikke begynner på noe nytt før hele troppen er ferdig med forrige oppgave. Selv om mange er ferdig og bare sitter og venter. Latency er venting og venting er ineffektivt.

[Reeve]

1.3 Mrd transistorer er jo bare ekstremt men hvar det mye å si på ytelse, når det er så mye?

Det er ett av spenningsmomentene hvilke applikasjoner som yter bedre og hvor mye bedre på grunn av L3 cachen.

 

og hva er forskjellen på L2 og L3 cache?

6692917[/snapback]

Det er bare nok et nivå:

- L1 har ekstremt lav latency men er til gjengjeld ekstremt liten

- L2 har lav latency men er til gjengjeld liten

- L3 har middels latency men er til gjengjeld middels stor

- Ram har treg latency men er til gjengjeld veldig stor

- Harddisk har ekstremt treg latency men er til gjengjeld ekstremt stor

 

Minnehireriarkiet er altså i stor grad styrt av mengde og latency. Jo lavere latency jo mer koster det per byte og jo større er de tekniske utfordringene med å lage stor lagringsplass. Et godt balansert minnehireriarki har passe store hopp i latency og mengde for hvert trinn.

6694167[/snapback]

 

 

Takk Simen1

[Vindstille]

Takk. Simen!

Fikk ikke tid til å lese det før nå. Men virkelig interessant.

Burda absolut tatt tid til å lære litt mer spessefikt om hvordan en datamaskin funker.

Endret 18. august 2006 av JonT

[Anders Jensen]

Noen ganger finner den ikke det den skal ha i L3 heller og da blir neste nivå hele 40-100 klokkesykluser unna før den får hentet noe fra ram.

6696336[/snapback]

Fin gjennomgang der. Bare en liten numerisk justering:

 

RAM latency ligger vel på 75ns til 200++ns litt ettersom hvor store maskinene er (75ns til 120ns for moderne singel sokkel maskiner tror jeg er ca. riktig). Med 2-4 sykluser per ns blir det 150-800++ sykluser venting for en last level cache miss.

 

effektiv latency er gitt ved

 

SUM(P_hit x avg_latency)

 

der P_hit er sjansen for å treffe i et gitt nivå i hierarkiet og avg_latency er gjenomsnittlig latency for samme nivået.

 

f.eks kan en ha (ikke noe konkret system brukt her:

 

L1 2 sykuser minimum, 2 sykluser snitt, 95% hit

L2 6 sykluser minimum, 7 sykluser snitt, 4% hit

L3 12 sykluser minimum, 16 sykluser snitt, 0,7% hit

RAM 200 sykluser minimum, 210 sykluser snitt, 0,3% hit

 

Effektiv latency blir:

(2 x 0,95) + (7 x 0,04) + (16 x 0,007) + (210 x 0,003)

= 1,9 + 0,28 + 0,112 + 0,63 = 2,922 sykluser i snitt

 

Både P_hit og avg_latency vil være variable med programmet som kjører selv innenfor samme hardware konfigurasjon. Noen programmer vil ha lite cache hit og noen vil ha høy cache hit, men også så høy båndbredde at avg_latency går opp litt pga køing i hierarkiet.

 

I regnestykket over ser det ut som om den største gevinsten ville kommet fra å kutte L1 latency fra 2 til 1 sykluser. Det er som regel også tilfellet for gjennomsnitlig latency, men det blir som regel ikke gjort fordi det er ganske enkelt å gjemme en latency på 2 sykluser i en moderne CPU kjerne og at de fleste opererer i 3GHz områet på 90nm - 65nm prosesser noe som ikke er forenelig med en 1 syklus L1 cache av nevneverdig størrelse. For x86 er det jo også såpass komplisert å kalkulere minneadressene at en gjerne bruker en ekstra syklus her.

 

Eneste moderne CPU jeg vet om med 1 syklus L1 cache er Itanium 2, men også her vil nok denne bli gjort om til (minst) 2 syklus L1 cache med tiden for å kunne oppnå høyere klokkefrekvenser.

[Quintero]

Eneste moderne CPU jeg vet om med 1 syklus L1 cache er Itanium 2, men også her vil nok denne bli gjort om til (minst) 2 syklus L1 cache med tiden for å kunne oppnå høyere klokkefrekvenser.

6704302[/snapback]

Hvordan fungerer det egentlig når SRAM initsierer både rad-aktivering og lese/skrive-operasjoner på samme syklus? Jeg forstår at SRAM ikke bruker adresse-multiplexing, men for DRAMs vedkommede er vel det bare halve problemet fordi minnet ikke kan respondere på lese/skrive-kommandoer før radens innhold er forsterket av charge amplifiers.

 

Er dette relatert til at rad-aktivering i SRAM ikke medfører destructive read, og at det dermed ikke er behov for charge amplifying og gjenoppretting av radens innhold?

Endret 19. august 2006 av Quintero

[Anders Jensen]

Eneste moderne CPU jeg vet om med 1 syklus L1 cache er Itanium 2, men også her vil nok denne bli gjort om til (minst) 2 syklus L1 cache med tiden for å kunne oppnå høyere klokkefrekvenser.

6704302[/snapback]

Hvordan fungerer det egentlig når SRAM initsierer både rad-aktivering og lese/skrive-operasjoner på samme syklus? Jeg forstår at SRAM ikke bruker adresse-multiplexing, men for DRAMs vedkommede er vel det bare halve problemet fordi minnet ikke kan respondere på lese/skrive-kommandoer før radens innhold er forsterket av charge amplifiers.

 

Er dette relatert til at rad-aktivering i SRAM ikke medfører destructive read, og at det dermed ikke er behov for charge amplifying og gjenoppretting av radens innhold?

6706631[/snapback]

At SRAM ikke har destructive read kan nok ha noe med saken å gjøre, men jeg vil tro at For L1 så er det mer organiseringen av minnecellene og dimensjoneringen av driver kretser som er avgjørende heller enn selve celle typen (DRAM vs. SRAM). L1 er som oftest en ganske ekstrem implementasjon. Det er veldig mye en kan gjøre på elektrisk nivå for å sprite opp hastigheten på en gitt komponent av en prosessor, men kostnaden viser seg gjerne i form av effektforbruk og størrelse på denne komponenten.

[Quintero]

At SRAM ikke har destructive read kan nok ha noe med saken å gjøre, men jeg vil tro at For L1 så er det mer organiseringen av minnecellene og dimensjoneringen av driver kretser som er avgjørende heller enn selve celle typen (DRAM vs. SRAM). L1 er som oftest en ganske ekstrem implementasjon. Det er veldig mye en kan gjøre på elektrisk nivå for å sprite opp hastigheten på en gitt komponent av en prosessor, men kostnaden viser seg gjerne i form av effektforbruk og størrelse på denne komponenten.

6709907[/snapback]

Takker for svar. Det med hastighet og organisering høres greit ut, men jeg grubler stadig mest over hva prosessene består av, og deres eventuelle rekkefølge. Uansett oppbygningen til DRAM-celler, må rad-signalet stabilisere seg før lese/skrive-prosessen i det hele tatt kan påbegynnes. Signalveien ved lesing blir grovt kategorisert slik:

 

Minneceller > Charge amplifiers (tRCD) > I/O gating (tCAS) > I/O interface

 

For SRAMs vedkommede regner jeg med at det ikke er noen charge amplifying med i bildet, fordi aktiveringen er non-destructive og fordi ladningene ikke taper seg over tid. Mtp at SRAM kan initsiere tRCD og tCAS samtidig blir det vel feil å snakke om noen rekkefølge. En annen ting er at forsinkelsen kan komme helt ned i en enkelt syklus. Dette mener jeg er nokså tydelige indikasjoner på at prosessene hovedsaklig består i lokalisering og overføring av dataene, uten at informasjonen i SRAM-cellene må klargjøres på noen måte. Men sikker er jeg ikke.

Endret 20. august 2006 av Quintero