Ny Itanium-lansering er utsatt

[int20h]

Itanium-kunder må vente helt til 2010 på "Tukwila"-prosessoren, som har blitt utsatt flere ganger tidligere.

 

Les mer

[Simen1]

Det snakkes om dobbel ytelse fra forrige Itanium-prosessor og en arkitektur som skal være kompatibel med Xeon-familien.

Jeg tror de snakker om sokkel-kompatibilitet med Xeon MP (LGA-1567) og dermed 4 QPI-busser + 4 kanaler FBDIMM-DDR3. (Jeg er litt forvirret ang. hvilket minne som kommer, men antar det blir DDR3-basert FBDIMM.)

 

Hva er forresten den klossen som ligger oppå waferen på bildet?

[Anders Jensen]

Jeg tror ikke det er snakk om sokkel kompatibilitet, men det finnes ingen bekreftende opplysninger om dette. Det er imidlertid bekreftet at Tukwila skal ha 6 QPI busser hvorav to er halv bredde pluss at den får 170W TDP hvilket er 40W mer enn Xeon MP sokkelen er bygd for, så det blir trangt i Xeon MP sokkelen. Mest sannsynlig er det QPI bussen og FBD-DDR3 broen som er fellesnevner for Tukwila og Xeon MP. Det vil si at de kan benytte samme minne og til en viss grad samme chipset. Hele poenget er å gjøre utviklingen av Itanium maskiner billigere ved å dele mest mulig av teknologien som utvikles for hig-end x86 maskiner. Det være seg interconnect protokoller, CMOS prosess, design biblioteker, og hele chipset.

 

Forresten synd at de måtte utsette Tukwila en gang til, men det er ikke så sjelden det skjer med high-end prosessorer. Toleransen for feil er svært liten og testingen veldig grundig. Det viktigste er egentlig å få testet ut den nye måten å koble prosessorene sammen på slik at dette er optimalisert til Poulson kommer. Det er uansett først da at Itanium kan bli en riktig suksess siden CMOS prosessen kommer opp på nivå med Xeon MP og er dermed ca 1 år før konkurrentene kommer med 32nm til samme maskinklasse. Tukwila er nå forsinket så mye at den ikke vil kunne bli den helt store suksessen. Det er tross alt et design som skulle vært ute i 2007. Får bare krysse fingrene for at Poulson kommer i tide og at Intel snart begynner med en versjon rettet mot de mindre 2P serverne.

Endret 25. mai 2009 av Anders Jensen

[Simen1]

Et kort tulleinnlegg med med Crysis som eneste poeng er slettet. Vennligst hold diskusjonen saklig og relevant. Evt. reaksjoner på modereringen skal tas på PM, ikke her i tråden.

[joffeloff]

Knotten på toppen av Tukwila er Atom.

[efikkan]

Det skal bli interessant å se om Itanium blir en stor suksess denne gangen.

[Anders Jensen]

Det skal bli interessant å se om Itanium blir en stor suksess denne gangen.

Det blir nok begrenset til high end markedet denne gangen også. Teknologien på kjernene, både med hensyn på mikroarkitektur og CMOS prosess (65nm) er så gammel at ytelsen per kjerne neppe gjør den interessant til HPC cluster og 2P servere. Skaleringen ser imidlertid veldig lovende ut og kan bli bedre enn IBM sin Power serie på enkelte oppgaver.

 

For at Itanium skal kunne treffe bredt så må Intel klare og levere med Poulson som er sokkel kompatibel med Tukwila og dermed får ferdig debuggede servere fra dag en og ikke minst er den nye og svært avanserte cache coherency teknologien, som skal ha gitt Tukwila forsinkelser, blitt utprøvd. Poulson blir lansert på 32nm CMOS prosess og er planlagt lansert rundt 2011, ca samtidig som Xeon MP kommer med 32nm prosess. Nå er også design bibliotekene til Itanium felles med de som benyttes i x86 prosessorer hvilket vil gjøre design arbeidet mye raskere.

 

De største spenningsmomentene rundt Poulson er den nye mikroarkitekturen samt 32nm prosessen som foreløpig er uprøvd.

Endret 26. mai 2009 av Anders Jensen

[Theo343]

Jeg forstår ikke poenget med x86 i denne sammenhengen. Er ikke dette en helt annen arkitektur, som mente å holde seg vekk fra x86, også instruksjonsmessig? Eller har man hele tiden kunnet kjøre x86 programvare på Itanium? Og snakker man ikke i tillegg om EM64T eller x86-64? Jeg vet at DECs Alpha i sin tid kunne kjøre en spesialversjon av NT4 og der kunne man emulere x86 programmer.

 

Hvilken programvare forbinder man ellers typisk med Itanium servere ( Leverandører, ikke bare kategorier )?

 

EDIT:

Jeg forstår at fordelen med at designbiblioteker er felles med x86 og at man deretter kompilerer for Itanium, men ellers virker dette forvirrende.

Endret 26. mai 2009 av Theo343

[Anders Jensen]

Theo343: tenker du på følgende setning?

"Nå er også design bibliotekene til Itanium felles med de som benyttes i x86 prosessorer hvilket vil gjøre design arbeidet mye raskere."

 

Det har ingenting med x86 instruksjonssettet å gjøre. Itanium hadde riktig nok x86 decoder i hardware i de to første generasjonene, men dette ble fjernet i forrige generasjon.

 

At design bibliotekene er felles går på hardware designet. Akkurat som at en software utvikler kan dra inn standard c++ bibliotek i steden for å skrive alt selv i assembler så kan også en hardware designer benytte standard biblioteker. Intel lager sine egne og tidligere har dette vært separate løp for Itanium og x86 hvilket betyr at en får mye dobbelt arbeid. Å benytte felles bibliotek vil også gjøre det enklere å benytte større blokker fra de andre design teamene. F.eks kan en hel ALU i en x86 og en IA64 implementasjon godt være identiske.

Endret 26. mai 2009 av Anders Jensen

[Theo343]

Skjønner (blandet først med software biblioteker).

 

Det jeg lurer på er dette fra artikkelen.

Dersom "Tukwila" skulle klare å stille med x86-ytelse for visse applikasjoner, kombinert med tradisjonelle Itanium-styrker, kan kanskje dette bli verdt å vente på allikevel?

Endret 26. mai 2009 av Theo343

[Anders Jensen]

Skjønner (blandet først med software biblioteker). Det jeg lurer på er dette fra artikkelen.

Dersom "Tukwila" skulle klare å stille med x86-ytelse for visse applikasjoner, kombinert med tradisjonelle Itanium-styrker, kan kanskje dette bli verdt å vente på allikevel?

 

Ja, det er vel bare standard hw.no vissvass? Emulering av x86 er i liten grad interessant i dag. Enten rekompilerer du eller så kjører du native. Det er kun de uheldige med EOL RISC basert software som emulerer, vel og merke hvis de ikke klarer å porte med transitive. Mesteparten av ny software som er veldig kode intensiv, altså mange millioner linjer kode, lages i Java for å sikre kompatibilitet på beste hardware i fremtiden. Så kompleks kode lever gjerne så lenge at det er umulig å si hva som er trenden innen den blir skiftet ut.

 

Edit: matcher edit i quote

Endret 26. mai 2009 av Anders Jensen

[Theo343]

Takker for oppklaring.

 

Hva slags software er typisk å kjøre for Itanium? Altså jeg tenker på hvorfor man ville vurdert å gå til innkjøp av Itanium istedet for x86 alternativet. En ting er den hardwaremessige ytelsesforbedringen man ville forvente, men tilgjengelig software er jo avgjørende.

 

Databaser? (hvilke leverandører)

Virtualisering? (hvilke leverandører)

Webservere

Applicationservere

osv?

 

Eks. kan jeg lese mye bla-bla om ESX og Itanium uten å finne noen support for det.

Endret 26. mai 2009 av Theo343

[Anders Jensen]

Godt spørsmål. IPF er ikke veldig attraktivt fra et rent ytelsesperspektiv per i dag, men det har bedre pålitelighet enn x86 og bedre ytelse enn tilsvarende x86 hardware med samme fartstid i markedet.

 

Java og .net kjører bra på IPF siden de har svært mye branches i koden. Samme med databaser. Skal du ha scale up Windows servere så er jo IPF standardløsningen. F.eks hvis du skal ha et kraftig MS SQL db cluster. Jeg tror imidlertid de fleste lander på Nehalem i dag, den er jo vesentlig kraftigere. Tukwila vil ta inn det gapet samt gjøre det mulig å skalere opp mye lengre, men da er jo Nehalem EX allerede ute. Nehalem EX er imidlertid ikke forventet å skalere noe bedre enn Opteron til 8-way systemer grunnet broadcast cache coherency og personlig er jeg skeptisk til at Nehalem EX sin L3 cache klarer å levere nok båndbredde til 8 kjerner. Tukwila har separat L3 per kjerne og dermed massivt høyere L3 båndbredde.

 

ESX er ikke supportert på Itanium, men det går en del rykter ja. Hadde definitivt vært interessant. Når du skal legge mange egg i en kurv så er det lønnsomt å investere i en kraftig og stabil kurv.

Endret 26. mai 2009 av Anders Jensen

[efikkan]

Det skal bli interessant å se om Itanium blir en stor suksess denne gangen.

<klipp>

Nå er jeg ingen Itanium-ekspert, men det jeg sikter til er min oppfatning av at Itanium har hatt gode kort på hånden (f.eks cache) uten at salget har blitt helt så stort som forventet. Enkelte har gått så langt som å hevde at Itanium ville bli ein braksuksess innenfor sitt segment.

[Anders Jensen]

Det skal bli interessant å se om Itanium blir en stor suksess denne gangen.

<klipp>

Nå er jeg ingen Itanium-ekspert, men det jeg sikter til er min oppfatning av at Itanium har hatt gode kort på hånden (f.eks cache) uten at salget har blitt helt så stort som forventet. Enkelte har gått så langt som å hevde at Itanium ville bli ein braksuksess innenfor sitt segment.

Det største problemet har vært og er forsinkelser. Det hjelper ikke å komme ut med en genial CPU på 3 år gammel CMOS prosess i mainstream server markedet.

 

Må innrømme at jeg hadde veldig stor tro på Tukwila, men når den blir 2-3 år forsinket i et marked der prosessorer blir ca dobbelt så kraftig annenhvert år så sier det seg selv at suksessen blir begrenset. Tukwila blir uansett en god kandidat til store maskiner med 8+ sokler. Der har nok ikke Xeon MP mye å stille opp med. Power 6+ har også problemer med å levere varene bedre enn power 6 så det kan nesten se ut som om SPARC blir den største konkurrenten på kort sikt hvis den klarer å levere til forventningene.

 

For mindre maskiner er det ikke mye håp før vi får Poulson. Der er fortsatt mye ukjent. Intel har ikke levert noe på 32nm enda og poulson blir sikkert ganske stor så prosessen må være veldig moden før den kan realiseres. Videre kommer det et nytt kjernedesign som det foreløpig ikke er noen kjente detaljer om. Antagelig har de minst to design og er i fasen med å bestemme hvilket de skal gå videre med.

 

Poulson blir det første Itanium designet hvor en har god kjenskap til hvordan kompilatorer kan generere IA64 kode _før_ kjernen designes. Det kan derfor være duket for en del radikale endringer i kjernene. Basert på forskning som er gjort på området er det særlig to teknikker som blinker seg ut.

 

Det ene er pipeline clustering som vil si at en splitter opp en kjerne i to eller flere pipelines med tette bånd innad i hver pipeline men svakere bånd mellom hver pipeline. Det er fortsatt en felles kontrollenhet og felles register slik at koden ikke ser de som separate pipelines. Fordelen er at smale pipelines kan klokkes mye raskere samtidig som koden kan kjøre på høy IPC siden det er flere pipelines. Ulempen er at en må enten i kjernen og/eller i kompilator søke å minimere datautveksling mellom hver pipeline for ikke å overbelaste koblingene samt at koblingene kan ha høyere forsinkelse. Vi snakker uansett mye tettere koblinger enn mellom tokjerner på samme chip. Typisk en ekstra syklus aksesstid pluss at det hele er transparent for software.

 

Det andre er runahead execution som blandt annet benyttes i Power6. Det er også foreslått en mer aggressiv variant av runahead kalt multipass. Poenget er å gi en in-order pipeline muligheten til å fortsette gjennom koden selv om den mangler data slik en out-of-order pipeline kan men med mye lavere kompleksitet i hardware, som igjen betyr høyere frekvens eller lavere effektforbruk. Ulempen er at runahead og multipass ikke kan bidra til å finne parallellitet på utføring av instruksjoner, kun parallellitet på aksess mot minne, som forøvrig er det største problemet per i dag ved siden av den økende kompleksiteten i out-of-order design. For Power6 er dette et problem som er blitt løst med bruk av SMT og svært høye frekvenser for å gi god ytelse med tilhørende effektforbruk. For Itanium vil ikke dette være en bekymring fordi kompilator allerede har beskrevet instruksjons parallelliteten så det er i grunn bare MLP (memory level parallelism) som gjenstår å finne.

 

http://impact.crhc.illinois.edu/ftp/confer...o-05-barnes.pdf

http://www-cse.ucsd.edu/~calder/papers/IPDPS-05-DCP.pdf

Endret 26. mai 2009 av Anders Jensen