Utsetter Tukwila

[int20h]

Firekjerneversjonen av Itanium blir utsatt av Intel enda en gang.

 

Les mer

[Anders Jensen]

Det er vel neppe noen overraskelse at HP vil være den største driveren for Tukwila siden Itanium strengt tatt er en videreføring av den velkjente Alfa-arkitekturen.

 

Det er vel strengt tatt ikke riktig. Itanium ble opprinnelig utviklet som etterfølgeren til PA-RISC. Den har imidlertid mye til felles med de fleste andre RISC instruksjonssett og har lånt et par knep fra både Alpha, MIPS og SPARC med unntak av organiseringen av instruksjonene der den er ganske enestående.

 

Koblingen mellom Alpha og Tukwilla er at det var Alpha EV7 design teamet som utviklet første utkast til denne prosessoren. Designet ble imidlertid funnet å være alt for ambisiøst og det ville trekke for mye effekt. Derfor ble kjernedesignet skrotet enn så lenge, oppfølgerne Poulson og Kittson vil nok ha noe av dette i seg da de kommer på hhv 32nm og 22nm og kan dermed rettferdiggjøre mer aggressive kjernedesign. Tukwilla fikk isteden den gamle Itanium 2 kjernen. Quickpath og minnekontrolerne samt cache coherency designet ble imidlertid videreført fra Alpha teamet sitt opprinnelige Tukwilla design og det er deler av dette vi allerede har sett i Nehalem.

 

Jeg mener dette designet først ble designet for Alpha EV8, en CPU som aldri ble bygd men som i likhet med det første Tukwilla designet også er ansett for å ha vært for aggressivt designet, så Nehalem eiere kan skryte på seg at de har litt Alpha historie i boksen sin. Det er imidlertid ikke så eksklusiv en klubb som en skulle tro. Alpha EV7 interconnect teknologien var vel noe av opphavet til Hypertransport som blant annet brukes av AMD.

Endret 6. februar 2009 av Anders Jensen

[Simen1]

Alpha EV6 resulterte i double pumped FSB på de opprinnelige AMD Athlon-prosessorene (K7-serien).

 

Alpha EV7 resulterte i HyperTransport og integrert minnekontroller, i AMD Athlon64-serien og Phenom-serien (K8, K10)

 

Alpha EV8 resulterer altså i QuickPath + integrert minnekontroller i Nehalem-serien og Tukwila.

 

Interessant at det er så mye godsaker å hente ut fra diverse ferdige og uferdige Alpha-design fortsatt.

 

AJ: Kritiserte ikke du lenge AMD for å velge integrert minnekontroller fordi du mente Xeons minnestruktur med mange minnekanaler mot ett brikkesett var en lurere løsning, også for multi-CPU-systemer, enn det AMDs grid-struktur var? Hvordan stiller du deg nå til disse designvalgene?

Endret 6. februar 2009 av Simen1

[Anders Jensen]

Interessant at det er så mye godsaker å hente ut fra diverse ferdige og uferdige Alpha-design fortsatt.

Det meste av "nye" ting som implementeres i PC er bare en miniatyrisering av noe IBM hadde i en mainframe for 30+ år siden. Ta virtualisering f.eks.

 

Stemmer forøvrig at jeg var, og er, kritisk til løsningen med distribuert og integrert minnekontroller. Selvfølgelig ser jeg fordeler med løsningen, men jeg liker vel gjerne å ikke være like halleluja-sveiseblind som enkelte var. Integrering av minnekontrolleren har også noen ulemper. F.eks blir det elektriske grensesnittet mer utfordrende både fordi det er en ekstra mekanisk kobling på minnebussen i form av CPU sokkelen og fordi det blir vesentlig trangere rundt sokkelen noe som gjør hovedkortene dyrere og minnekapasiteten dårligere. Dette ble jo faktisk et reelt problem for AMD i begynnelsen med noe trøblete minnestøtte og behov for slappere innstillinger for å få stabile linjer, eller husker jeg feil? Var ekstremt mye bråk rundt dette... Videre blir en mer låst til gamle teknologier når en integrerer mer på samme brikke, så også med IMC. f.eks må en nå redesigne en vesentlig større del av systemet før en får satt endringene ut i live. Noe overgangen fra DDR til DDR2 og videre til DDR3 viste i praksis.

 

Kan vel si at DDR/DDR2/DDR3 + IMC + server plattform ikke er 100% gunstig pga. kapasitetsproblemer. Videre kom scheduling og NUMA som var dårlig støttet i OS for kun få år siden og medførte at mye av det en tjente ble tapt i OS. Nehalem har vel også sørget for at annenhver CPU (nr, 0, 1, 2 osv.) ligger på forskjellige sokler i et 2-way system for å forhindre at OS skal gjøre scheduling av tråder på kun en sokkel. Løsningen med interleaving av IMC var også fullstendig bortkastet synes jeg. Hva er poenget når halvparten av minneaksess får høyere latency uansett hvor smart OS prøver å være?

 

Hadde vi hatt RD-RAM ville IMC gitt mye mer mening, men RD-RAM fikk vi ikke pga DRAM kartellene og nyttige idioter i pressen som la skylden på RAMBUS, som vel tok mindre royalties for RD-RAM enn DDR-DRAM til slutt... Dermed fikk vi heller ikke Timna, en P3 basert x86 CPU med RD-RAM IMC, som ville gitt Intel en grell ledelse i det mobile markedet. Isteden fikk vi P4-m. ? Løsningen med serielt grensesnitt fra CPU til ekstern buffer på hovedkortet slik vi får med Tukwilla og Xeon MP er god med tanke på kapasitet, men vil koste litt mer i form av effektforbruk og forsinkelse.

Endret 6. februar 2009 av Anders Jensen

[Dan-The-Man]

Litt spam det her men.

Jeg er må bare si at jeg er sykt imponert over nivået det diskuteres på her. gudhjelpemeg det hadde vært soft å hatt såpass peiling.

(heldigvis er det andre ting jeg kan godt)