Itanium 2 vinner terreng

[el-asso]

Dette med pris ytelse er selvsagt viktig for sluttbrukeren og det er ingen tvil om at Itanium har lite å stille opp med på det området( foreløpig?)

 

Når jeg likevel har tro på EPIC/IPF så har det først og fremst årsak i problemene med pipelining. Fordi Intel har tynt arkitekturen mest og møtt veggen først kan vi bruke Northwood og Prescott’s pipeline som utgangspunkt. Denne er riktignok ikke direkte overførbart til for eksempel AMD’s prosessorer med vesentlig færre steg i pipelinen, dessuten har AMD vært flinkere ”mekanikere” på produksjonssiden enn Intel (bla. varme), men tilsvarene de arkitekturmessige begrensningene Intel har møtt p.g.a. dybden på pipelinen møter også AMD ettersom det begrenser seg hvor bred pipeline de kan takle ( pipeline stalls er like uønsket uansett om de kommer i en dyp eller bred pipeline).

 

Så, for Intels’s del har det vært snakk om stadig dypere pipeline for dermed å øke klokkefrekvensen. Greit nok i en ideell verden, jo flere steg i pipelinen jo kortere tid tar hver klokkesyklus, flere instruksjoner kan befinne seg samtidig i pipelinen og programmet som kjører utføres raskere. Så møter man den virkelige verden der det er problemer p.g.a ”Pipeline Stalls”, det begrenser seg hvor mange ”Branch Prediction” en kan ha og til slutt klarer en heller ikke å lage en pipeline med flere steg eller større bredde.

 

Teknikkene en bruker for å rette opp i svakhetene til dagens pipelining ser altså ut til å ha nådd det maksimale av hva en kan forvente. Selv om en dytter inn flere transistorer, er matematikken bare i begrenset stand til å unngå mer misprediction enn i dag med mindre dette skjer på et tidligere stadium i prosessen, nemlig på kompilator og/eller program nivå.

Det er pg.a. det siste jeg tror Itanium har noe for seg, man vil ”møte veggen” on-die, Potensialet for forbedringer er etter min mening større ved å eksekvere uavhengige instruksjoner parallelt på instruksjonsnivå (ILP), selv om det som kjent gjenstår mye her også.

 

Når det gjelder flerkjerneprosessorer vet jeg ikke om det bare skal tolkes som en måte å utsette levetiden til en x86 arkitektur som drar på årene, eller om det er en (kostbar?) forbedring som blir vanlig i fremtiden.

Uansett tror jeg Itanium overlever x86 og ikke motsatt.

[snorreh]

For det første så løser ikke Itanium problemene med "pipelining", siden den også sliter med å få utnyttet alle eksekveringsenhetene sine (faktisk er den mindre effektiv på dette enn dagens x86-prosessorer) og det gjenspeiler seg i svak ytelse. For det andre så legger Intel nå til SMT-støtte på fremtidige Itanium-prosessorer og det er et klart tegn på at det ikke er så mye mer å hente på ILP siden man må benytte seg av andre teknikker for å øke effektiviteten. K8 og PM er eksempler på at x86-prosessorer fortsatt har en del å gå på mhp. forbedring av "branch (mis-)prediction", så jeg har liten tro på din pessimisme her. x86-prosessorer yter i praksis bra på det aller meste, men det samme kan ikke sies om Itanium dessverre så her er det fortsatt et stort gap mellom teori og praksis. Det er også lite som tyder på at Itanium vil bli mer effektiv og kostnadsgunstig med det aller første heller, og hvis man studerer veikartene til Intel så er det ingenting som tyder på at dette kommer til å endre seg radikalt de nærmeste 2-3 årene. Jeg holder fortsatt en knapp på x86(-64) iallefall inntil det motsatte er bevist (teori = praksis for Itanium), siden x86 tross alt representerer en meget robust arkitektur som har overlevd alt annet sålangt.

Endret 15. november 2004 av snorreh

[el-asso]

For det første så løser ikke Itanium problemene med "pipelining", siden den også sliter med å få utnyttet alle eksekveringsenhetene sine (faktisk er den mindre effektiv på dette enn dagens x86-prosessorer) og det gjenspeiler seg i svak ytelse. For det andre så legger Intel nå til SMT-støtte på fremtidige Itanium-prosessorer og det er et klart tegn på at det ikke er så mye mer å hente på ILP siden man må benytte seg av andre teknikker for å øke effektiviteten. K8 og PM er eksempler på at x86-prosessorer fortsatt har en del å gå på mhp. forbedring av "branch (mis-)prediction", så jeg har liten tro på din pessimisme her.

Det er mulig dette ikke kom klart nok fram i det jeg skrev tidligere, Itanium løser ikke problemene med pipelining, derimot ser jeg på ILP som et mulig alternativ til å bedre instruksjonsflyten i pipeline. Og jeg er rimelig pessimistisk med tanke på x86 og "pipeline-stall". Hadde designerne kunne løse dette hadde vi antakelig ikke hatt innføring av dobbelkjerne så raskt som annonsert.

 

Jeg er enig i at fremtiden til x86 ser adskillig lysere ut med innføring av dobbelkjerne, SMT og eventuelt SMP, men ingen av disse tingene løser den grunnleggende svakheten med x86 og pipeline. Her tror jeg i motsetning til deg at løsningen vil være å flytte over oppgaver på kompilatornivå fremfor å legge mer og mer "on-die".

 

At Intel legger inn SMT støtte på Itanium trenger ikke være et tegn på at de har gitt opp ILP, det kan også være et "ja takk, begge deler".

[Knick Knack]

At Intel legger inn SMT støtte på Itanium trenger ikke være et tegn på at de har gitt opp ILP, det kan også være et "ja takk, begge deler".

Riktig observert. Dessuten er det ikke SMT de innfører, men soe-MT (Switch On Event Multi Threading). Det vil si at hver kjerne bare kjører en tråd av gangen. soe-MT har altså ingen ting med ILP å gjøre den sørger bare for at kjernen skifter tråd automatisk hvis det oppstår en "event" som medfører en lengre stall av tråden. En slik stall kan oppstå ved f.eks L3 cache miss (ca 400 sykluser for 1.6GHz/400FSB versjonen), eller IO (mildt sagt mange sykluser).

 

Andre myter som er greit å feie av veien:

 

Flere execution units medfører ikke automatisk mer parallellitet. En må også ha en krets som verifiserer denne parallelliteten for å unngå RAW (read after write) hazard. Altså at en utfører en instruksjon der en er avhengig av et resultat som ikke er ferdigberegnet. En trenger også en krets som holder styr på hvilke resultater som blir tilgjengelige om "noen sykluser" og dermed velge en rekkefølge som er mest mulig optimal i forhold til de ressursene prosessoren har (OOE, Out of Order Execution). Disse kretsene som verifiserer og finner ILP har i de siste designene medført en stadig økning av kompleksitet i den fremste delen av pipelinen, altså før execution, selve execution delen er rimelig rett frem. Det har igjen resultert i lengre pipelines eller lavere økning i frekvens i forhold til hvor mange pipeline steg en legger til. IPF har ikke disse kretsene siden dette gjøres i kompilator. Dette er hovedforskjellen på IPF og "alle andre" dvs RISC og CISC. Alt det andre "snackset" som er lagt til IPF er av mindre betydning og mye av det er stort sett funksjonalitet som skal oppveie for ulemper ved VLIW lignende design.

 

Det begynner nå å gi avkastning i form av både ytelse og ytelse/watt:

http://www.hp.com/products1/servers/integr...fact_sheet.html

Du skal lete lenge etter en 1U server med mer FP ytelse og billigere pris enn HP rx1620-2 utstyrt med 1.6GHz Itanium 2, 3MB L3 cache og 533FSB. Med 4-way Opteron får du ~40% høyere FP ytelse, men det koster.

 

Kort sagt; bølgen er i ferd med å bygge seg opp:

http://www.newratings.com/analyst_news/article_509310.html

Endret 15. november 2004 av Knick Knack

[snorreh]

Det er mulig dette ikke kom klart nok fram i det jeg skrev tidligere, Itanium løser ikke problemene med pipelining, derimot ser jeg på ILP som et mulig alternativ til å bedre instruksjonsflyten i pipeline.  Og jeg er rimelig pessimistisk med tanke på x86 og "pipeline-stall".  Hadde designerne kunne løse dette hadde vi antakelig ikke hatt innføring av dobbelkjerne så raskt som annonsert.

 

Jeg er enig i at fremtiden til x86 ser adskillig lysere ut med innføring av dobbelkjerne, SMT og eventuelt SMP, men ingen av disse tingene løser den grunnleggende svakheten med x86 og pipeline.  Her tror jeg i motsetning til deg at løsningen vil være å flytte over oppgaver på kompilatornivå fremfor å legge mer og mer "on-die".

Nei, integrering er fremtiden etter min mening. Itanium er et eksempel på at kompilatoren ikke klarer å gjøre oppgaver mer effektivt enn "on-die". En av ulempene med å flytte oppgaver over på kompilatornivå er at koden vokser nesten eksponensielt, og man får en stor "overhead" som reduserer ytelsen samtidig som systemressursene blir lite effektivt utnyttet. Det at Itanium må ha så stor cache for å yte brukbart viser dette (ref. Merced vs. McKinley).

 

At Intel legger inn SMT støtte på Itanium trenger ikke være et tegn på at de har gitt opp ILP, det kan også være et "ja takk, begge deler".

Tja, noen vil sikkert påstå dette men jeg er ikke helt med på det. Ytelsesforbedringer via ILP på Itanium har nesten stått stille det siste halvannet året, og jeg har liten tro på at det kommer til å bedre seg radikalt den nærmeste fremtid så da er kanskje SMT og SMP eneste utvei for å øke effektiviteten og dermed ytelsen.

[snorreh]

På aces har diskusjonen om IPF på spillkonsoll så smått begynnt å rulle:

IA-64 as a gaming processor (Xbox 3?)

 

Selv har jeg lite tro på dette foreløpig, men hvem vet. IPF egner seg godt til denne typen oppgaver. Som mange påpeker er det også et lass av oppgaver som gjøres i CPU og som ikke kan gjøres i GPU. Artig tråd synes jeg.

Ja, morsomt å lese - spesielt dette innlegget av Vincent Diepeveen synes jeg var bra:

 

Why itanium is wrong in so many ways

The real bottlenecks of itanium2 are:

  a) it released years too late

  b) it is a SPEC processor.

  c) it doesn't clock high enough

  d) it's too expensive for what it delivers

  e) the 2nd law of Moore outdated it

 

Spec processor i mean with it is just performing well on that very tiny testset called spec2000 and no doubt it will do well on the new tiny spec2004 testset.

What works well for spec is having a small L1 cache. I know many hardware engineers disagree here with me, but please face the facts. Intel is the ONLY company who has a line of processor series with tiny L1 caches. All its competitors have BIG L1 caches. Tiny L1 cache is ok for spec. Not in real life however.

 

Open source programs simply tend to be way smaller than real life programs and especially GAMES where people care about.

 

And no, i won't give my diep source code to spec either. *everyone*, so also my competitors, can then buy for a small amount of money my source code.

 

Points c,d,e are all related to each other. The 2nd law of Moore is that a doubling of transistors also means a doubling in price for the factories producing those processors.

 

Those processor factories ever get more expensive. Let me quote intel's own research: they fear the next generation factory to cost 20 billion dollar.

 

Those dollars must get earned back. Intel sells around 100k itaniums a year, but also sold over a billion pc processors past years. Each quarter tens of millions of pc processors get sold by intel.

 

So basically the total earnings on itanium, of course so far it didn't deliver any profit, they are a peanut compared to the pc processors.

 

Trivially that means that the itanium still is in 0.13 technology and will remain so until 2006 or so, where the pc processors are already in the more fine grained 0.09 technology. So itanium simply runs a generation in technology behind.

 

Whatever the excuses some hardware guys give for that, it's simply running that generation behind. PERIOD.

 

So it will NEVER be able to compete with pc processors.

 

It's not worth the EARNINGS simply.

 

This where a highend processor that's similar to a pc processor (at most a bit more or less cache) will be able to be printed in the latest technology.

 

So the speed difference each year will be less of an advantage to highend processors thanks to the huge technology advantage of the pc processors.

 

Additionally, the smaller effort that gets put in highend processors such as itanium, means that they never will clock as high as a pc processor does in such technology.

 

It just runs years behind simply.

 

A result of the small number that gets printed and the huge surface it eats, means the price of such a highend processor is way way bigger than a pc processor.

 

This combined with the fact that the new generation supercomputers have so many processors (way over 10000), that only embarassingly parallel software can run on such supercomputers.

 

So Seymour Cray's statement is outdated by now: "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?"

 

The only real big advantage highend processors used to have is that they were 64 bits. Nowadays that also isn't the case anymore. They're all 64 bits now. So any 64 bits pc processor that gets a decent number of gflops a dollar, can be put in such massive supercomputers in the future (of course given the constraints of that it needs to have a bit of ECC and such).

 

A 1024 processor chicken processor supercomputer simply is way cheaper than a 240 processor itanium2.

 

You can brag about itanium2's most expensive model with a 667Mhz chipset, which earliest around 2006 can be put in supercomputers, and which processor you can buy for perhaps 8000 dollar a piece if you buy 1000 of them, you sure can brag about the floating point 1 such processor gives.

 

But apart from that you can create a supercomputer start of 2006 earliest with it, what will the price of it be?

 

Factor 4 more expensive than a opteron-cray XD1 which delivers the same number of gflops?

 

Also that Cray you can get today.

 

How about the year 2007?

 

A 2.2Ghz montecito dual core, delivering 12 gflop, with 667Mhz chipset (so 4 processors must read to a single chip set dividing the bandwidth of that single chipset; compare with on die memory controllers which can deliver 2.2ghz a cpu), will be the state of the art then that intel can deliver.

 

A single quad itanium (which manufacturer will deliver it now that we know windows won't run at it either?) can therefore deliver for the price of 100000 dollar about 48 gflop.

 

For the same price we can of course buy a 2 machines 8 processor dual core 4Ghz opteron (or perhaps by then intel also has a pc processor alternative which i DOUBT by the way, but ibm and sun for sure will have).

 

Each dual core 4Ghz opteron can deliver 16 gflop. In total such machine delivers then 108 gflop and we can buy 2 of them for that price = 216 gflop.

 

There you go...

Endret 15. november 2004 av snorreh

[Knick Knack]

snorreh: Jeg inser at du ikke ønsker å erkjenne at jeg bruker dette forumet, men for å sikre at andre som leser denne tråden ikke kjøper alle faktafeilene du slenger rundt deg (for vi diskuter jo som tidligere nevnt ikke fakta...):

 

Itanium er et eksempel på at kompilatoren ikke klarer å gjøre oppgaver mer effektivt enn "on-die".

IPF har høyere ytelse/MHz enn de aller fleste arkitekturer i de aller fleste applikasjoner. Eneste gode unntaket jeg kjenner til er sjakk spillet DIEP. (Edit: forøvrig skrevet av Vincent Diepeveen en kjent IPF hater).

 

En av ulempene med å flytte oppgaver over på kompilatornivå er at koden vokser nesten eksponensielt, og man får en stor "overhead" som reduserer ytelsen samtidig som  systemressursene blir lite effektivt utnyttet.

OK for det første er IA64 kode ca 3x større enn IA32 kode. 3x er en konstant. Matematiske begreper burde være unødvendig å diskutere.

 

Det er også allment anerkjent at code size ikke er viktig med mindre en oppererer i embedded markedet hvor effektforbruk og minnekapasitet er de kritiske faktorene i dag. Det betyr forøvrig ikke at de vil være det i fremtiden. Typisk endrer det seg hva som er de mest kritiske faktorene ettersom teknologien utvikler seg.

 

Forøvrig er time/space omforminger en mye brukt teknikk for å redusere tid på bekostning av plass.

 

Det at Itanium må ha så stor cache for å yte brukbart viser dette (ref. Merced vs. McKinley).

Spesielt eksempel. Merced (Itanium 1) har langt lavere ytelse ved 4MB L3 cache enn McKinley (Itanium 2) med 1.5MB L3 cache.

 

Ytelsesforbedringer via ILP på Itanium har nesten stått stille det siste halvannet året(..)

Merkelig det der... Det har jo ikke vært endringer i kjernen i samme tidsrommet. Kompilator forbedringer har imidlertid ført til at IPF har utviklet seg fra å være dårligst i klassen på java til å være best i klassen på Java i samme tidsrommet.

 

Edit: ser du har lagt ned boikotten av mine poster i mellom tiden. Fint det. Har selv lest innlegget til Vincent Diepeveen tidligere i dag og kan ikke si jeg er imponert. Det har så mange feil og tynne antagelser (som at Intel bevist kommer til å prise seg ut av markedet) at jeg ikke fant det interessant å dissekrere den. Har rett og slett ikke tid. Står det mellom Seymour Cray og Vincent Diepeveen så tar jeg Cray sin oppfattelse av virkeligheten uten å nøle. Singel thread ytelse er viktig og det vil det fortsette å være i lang tid.

Endret 15. november 2004 av Knick Knack

[Boralis]

Knick Knak , vi som liker Intel er jo ikke seriøse nok , så derfor har enkelte lagt ned boikott , vi klipper og limer ikke de riktige sitatene skjønner du

[snorreh]

Jeg inser at du ikke ønsker å erkjenne at jeg bruker dette forumet, men for å sikre at andre som leser denne tråden ikke kjøper alle faktafeilene du slenger rundt deg (for vi diskuter jo som tidligere nevnt ikke fakta...)

Noen etterlyste meninger fra meg og nå er det også feil?

 

Itanium er et eksempel på at kompilatoren ikke klarer å gjøre oppgaver mer effektivt enn "on-die".

IPF har høyere ytelse/MHz enn de aller fleste arkitekturer i de aller fleste applikasjoner. Eneste gode unntaket jeg kjenner til er sjakk spillet DIEP.

Itanium har ikke bevist noe som helst mhp. ytelse annet enn i Spec-tester o.l. Saken er at ILP på Itanium er veldig lite effektiv sammenlignet med "on-die" på x86-prosessorer, et faktum du ikke kommer deg bort fra. Ytelse/MHz er bare et halmstrå du klynger deg til, det som teller i virkeligheten er ytelse/pris og ytelse/watt og innen disse områdene henger Itanium håpløst etter.

 

En av ulempene med å flytte oppgaver over på kompilatornivå er at koden vokser nesten eksponensielt, og man får en stor "overhead" som reduserer ytelsen samtidig som  systemressursene blir lite effektivt utnyttet.

OK for det første er IA64 kode ca 3x større enn IA32 kode. 3x er en konstant. Matematiske begreper burde være unødvendig å diskutere.

Saken er at Itanium-kode er såkalt "bloatware" dvs. den er meget systemkrevende mhp. cache- og minnebruk, altså lite effektiv sammenlignet med x86-kode.

 

Det at Itanium må ha så stor cache for å yte brukbart viser dette (ref. Merced vs. McKinley).

Spesielt eksempel. Merced (Itanium 1) har langt lavere ytelse ved 4MB L3 cache enn McKinley (Itanium 2) med 1.5MB L3 cache.

Nei, jeg snakket selvsagt om Merced 733MHz med 96KB L2 cache og 2MB L3 cache vs. McKinley 1000MHz med 256KB L2 cache og 3MB L3 cache (begge har like "mye" L1 cache, altså 32KB).

 

Ytelsesforbedringer via ILP på Itanium har nesten stått stille det siste halvannet året(..)

Merkelig det der... Det har jo ikke vært endringer i kjernen i samme tidsrommet.

Jeg snakker selvsagt om forbedring av ytelse på kompilatornivå, for her har det ikke skjedd så mye dramatisk det siste halvannet året akkurat.

Endret 15. november 2004 av snorreh

[Knick Knack]

Jeg inser at du ikke ønsker å erkjenne at jeg bruker dette forumet, men for å sikre at andre som leser denne tråden ikke kjøper alle faktafeilene du slenger rundt deg (for vi diskuter jo som tidligere nevnt ikke fakta...)

Noen etterlyste meninger fra meg og nå er det også feil?

For all del kom med meningene dine, men ikke presenter de som fakta uten å kunne bevise det.

Saken er at ILP på Itanium er veldig lite effektiv sammenlignet med "on-die", et faktum du ikke kommer deg unna.

Det er et "faktum" jeg kan komme meg unna ti ganger før frokost, så bare skyt med noe konkret.

Saken er at Itanium-kode er såkalt "bloatware" og meget systemkrevende mhp. cache og minnebruk, altså lite effektiv sammenlignet med f.eks. x86-kode.

Dette har du selvsagt ingen beviser for, og det faktum at Alpha (og all annen RISC kode) er langt mer "bloat" enn x86 sier jo sitt om den saken.

 

Det at Itanium må ha så stor cache for å yte brukbart viser dette (ref. Merced vs. McKinley).

Spesielt eksempel. Merced (Itanium 1) har langt lavere ytelse ved 4MB L3 cache enn McKinley (Itanium 2) med 1.5MB L3 cache.

Nei, jeg snakket selvsagt om Merced 733MHz med 96KB L2 cache og 2MB L3 cache vs. McKinley 1000MHz med 256KB L2 cache og 3MB L3 cache.

Denne her ville jeg ikke forsøkt å forsvare noe mer var jeg deg. Dette er som å sammenligne Pentium M og Pentium 4 for så å påsta(å?) at cache er forskjellen. Seriøst, Itanium 2 har 4 ganger raskere FSB og nesten dobbelt så mange M, I og B units som Itanium 1!

Jeg snakker selvsagt om forbedring av ytelse på kompilatornivå, for her har det ikke skjedd så mye dramatisk det siste halvannet året.

Da har du ikke fulgt med. Ytelsen har skutt i været. Her er ett bevis:

http://www.spec.org/jAppServer2002/results...0130-00021.html

http://www.spec.org/jAppServer2002/results...0914-00030.html

Opp 20% på et halvt år på samme system.

Endret 15. november 2004 av Knick Knack

[Knick Knack]

Informativ artikkel om Itaniums fremtid kom nettopp her:

http://www.informationweek.com/story/showA...icleID=52601361

 

Opp til 200% ytelsesøkning med Montecito.. Komer til å gjøre susen det.

 

Analysts are cautiously optimistic over Itanium's future. Says Gordon Haff, an analyst with Illuminata: "I don't see in the near to midterm a clear knockout winner between x86, Power, and Itanium in this space, but Itanium is clearly a contender."

clearly!

 

Når jeg først driver å quoter:

"A lot of architectures are going to hit the wall, so to speak, but [Montecito's] multicore solution could be a deployable answer" to heat and power dissipation, says Jeff Greenwald, senior director of server product management and marketing at SGI, "giving me another 10 years before I have to look at another architecture."

Det er akkurat dette jeg selv fant ut da jeg leste meg opp på computer architecture i sommer. RISC og CISC er i ferd med å treffe veggen. Enten når de høy frekvens (P4) eller så når de høy IPC (K8, Dothan). Begge deler ser ut til å bli umulig. IA64 kombinerer frekvens og IPC langt bedre enn RISC som igjen er noe bedre enn x86 (CISC). ref. PowerPC. Itanium ligger riktig nok etter k8 og Dothan på frekvensspekteret, men den tar inpå. Montecito blir det utlimate beviset... Den er forøvrig allerede levert til utvalgte OEMs for testing i følge Intel selv! Endret 15. november 2004 av Knick Knack

[el-asso]

Ja, morsomt å lese - spesielt dette innlegget av Vincent Diepeveen  synes jeg var bra:

 

Why itanium is wrong in so many ways

The real bottlenecks of itanium2 are:

  a) it released years too late

  b) it is a SPEC processor.

  c) it doesn't clock high enough

  d) it's too expensive for what it delivers

  e) the 2nd law of Moore outdated it

 

 

a) it released years too late

Noen vil kanskje si IPF er forut for sin tid og vil mislykkes av den grunn. Må innrømme at jeg har problemer med å ta poenget (at det har godt lang tid fra prosjektet ble startet til produktet lå på bordet?)

 

  b) it is a SPEC processor.

Her er det vel nok av tråder (nyhetsmeldinger) som viser at sluttbrukerne ser på Itanium som noe mer en det.

 

c) it doesn't clock high enough

Høyt nok i forhold til hva ? Opteron ? Handler det ikke om hvor raskt instruksjonene fra programmet kan utføres og ikke hvor mange MHz prosessoren som utfører instruksjonene opererer på.

 

  d) it's too expensive for what it delivers

Blir litt diffust dette, Itanium er (foreløpig) dyrt, antakelig ogå høy pris/ytelse, men det er vel ikke noe spesielt i introduksjonsfasen for et produkt.

(ja, jeg regner fortsatt IPF for å være i introduksjonsfasen)

 

  e) the 2nd law of Moore outdated it

Kunne være fristende å snu det på hodet å si at IPF "outdated" Moore's 2.law, men det er noe tidlig enda.

 

Jeg kan ikke si at denne artikkelen imponerte hverken i stil eller innhold.

[snorreh]

Saken er at ILP på Itanium er veldig lite effektiv sammenlignet med "on-die" x86-prosessorer, et faktum du ikke kommer deg unna.

Det er et "faktum" jeg kan komme meg unna ti ganger før frokost, så bare skyt med noe konkret.

Jeg baserer det på egne erfaringer med sammenligning av Java-ytelsen på Itanium2 vs. Xeon DP vs. Opteron under Linux. Disse viser samme tendensene som de fleste andre "real life" tester, nemlig at Itanium2 yter svakere i praksis.

 

Saken er at Itanium-kode er såkalt "bloatware" og meget systemkrevende mhp. cache og minnebruk, altså lite effektiv sammenlignet med f.eks. x86-kode.

Dette har du selvsagt ingen beviser for, og det faktum at Alpha (og all annen RISC kode) er langt mer "bloat" enn x86 sier jo sitt om den saken.

Nei, det stemmer ikke. Jeg har faktisk sammenlignet kode for Itanium2 og x86-prosessorer og det er veldig stor forskjell skal jeg si deg, 3x større enn x86-kode gjelder bare i beste fall. Til sammenligning er x86-64 kode bare ca. 20% større. Hvis du ikke tror meg så er du velkommen til å teste selv, du kommer til å bli negativt overrasket.

 

Nei, jeg snakket selvsagt om Merced 733MHz med 96KB L2 cache og 2MB L3 cache vs. McKinley 1000MHz med 256KB L2 cache og 3MB L3 cache.

Denne her ville jeg ikke forsøkt å forsvare noe mer var jeg deg. Dette er som å sammenligne Pentium M og Pentium 4 for så å påsta(å?) at cache er forskjellen. Seriøst, Itanium 2 har 4 ganger raskere FSB og nesten dobbelt så mange M, I og B units som Itanium 1!

Det er stor konsensus om at cache var den største flaskehalsen mhp. ytelse til Itanium1 (Merced), og den har økt hele tiden fra McKinley (3MB), Madison (9MB) og Montecito (24MB). Det er ikke å sammenligne epler og pærer, ettersom alle tilhører IPF.

 

Jeg snakker selvsagt om forbedring av ytelse på kompilatornivå, for her har det ikke skjedd så mye dramatisk det siste halvannet året.

Da har du ikke fulgt med. Ytelsen har skutt i været. Her er ett bevis:

http://www.spec.org/jAppServer2002/results...0130-00021.html

http://www.spec.org/jAppServer2002/results...0914-00030.html

Opp 20% på et halvt år på samme system.

Spec-tester er neppe noe bra bevis for forbedring av kompilator-ytelse, ettersom en 10% forbedring i Spec-tester i beste fall kan overføres til 1-2% bedring i ytelsen på reelle problemer. Det er heller ikke alle Spec-optimaliseringer som kan direkte overføres til andre problemer, siden disse testene er veldig cache-betinget.

 

Fluent har nå forøvrig kommet med oppdaterte benchmarks for Itanium2, Power5, Opteron, Xeon m.fl:

http://www.fluent.com/software/fluent/fl5bench/fullres.htm

 

Fluent er som kjent et veldig minneintensivt og flytetallsintensivt simuleringsprogram, og som du ser så sliter faktisk Itanium2-systemene fra HP med å følge med Opteron-systemene fra SUN...

Endret 15. november 2004 av snorreh

[Knick Knack]

el-asso: Er rimelig enig i din kommentar til Vincent Diepeveens punkter. Det eneste punktet han egentlig har noe å fare med, er punkt b) "it is a SPEC processor". Det er til en viss grad riktig, og som han sier så er grunnen til dette at IPF bare har 16kB L1 cache. At en prosessor er god på SPEC_CPU testene er imidlertid ikke en negativ egenskap, men det er riktig at en del, spesielt nyere, programvare drar nytte av større, men da også tregere L1 cache. Typisk er det avveiningen mellom 1 cycle latency og 3 cycle latency L1 cache han angriper her. Intel bruker konsekvent 1 cycle L1 cache latency i Itanium og da får de ikke mer enn 16kB. Sånn er det bare. Likt for alle her, så lenge en kjører på ca samme klokkefrekvens. Andre produsenter benytter ofte 3 cycle L1 cache latency og da får de ca 64kB L1 cache. Også dette er rimelig likt for alle produsenter som velger denne løsningen.

 

I de kommende Montecito og Millington prosessorene vil Intel nærme seg ønsket til Vincent noe mer ved at de implementerer Harvard-style L2 cache som gir en stor instruksjon (I-)cache på 1MB som antagelig ikke vil være mye tregere enn store delte L1 cache løsninger. Dermed skulle "it is a SPEC processor" merkelappen være upassende fra og med neste generasjon IPF.

Endret 15. november 2004 av Knick Knack

[snorreh]

Informativ artikkel om Itaniums fremtid kom nettopp her:

http://www.informationweek.com/story/showA...icleID=52601361

Ja, helt klart interessant den der på sett og vis.

"A lot of architectures are going to hit the wall, so to speak, but [Montecito's] multicore solution could be a deployable answer" to heat and power dissipation, says Jeff Greenwald, senior director of server product management and marketing at SGI, "giving me another 10 years before I have to look at another architecture."

Han snakker tydeligvis om dual-kjerne P4/Xeon her, for Montecito har neppe særlig å stille opp mot mhp. lavere varmeproduksjon og strømforbruk enn f.eks dual-kjerne K8/PM.

 

Du glemte å ta med dette interessante sitatet da:

Sun, which this week takes the final wraps off its Solaris 10 operating system, and IBM, whose Power5 processor leads in the highest-performance computing segment, believe there is life beyond Wintel.

 

Sun says no customers have asked it to support Itanium-based systems. But it's moving aggressively to provide systems based on Advanced Micro Devices Inc.'s x86-compatible Opteron processor, says John Loiacono, executive VP of Sun's software group.

[Knick Knack]

Ja, helt klart interessant den der på sett og vis.

"A lot of architectures are going to hit the wall, so to speak, but [Montecito's] multicore solution could be a deployable answer" to heat and power dissipation, says Jeff Greenwald, senior director of server product management and marketing at SGI, "giving me another 10 years before I have to look at another architecture."

Han snakker tydeligvis om dual-kjerne P4/Xeon her, for Montecito har neppe særlig å stille opp mot mhp. lavere varmeproduksjon og strømforbruk enn f.eks dual-kjerne K8/PM.

Som det fremgår av teksten så er det Montecito han snakker om. Tro det eller ei. Selv har jeg sett den utviklingen i snart et år.

[snorreh]

Han snakker tydeligvis om dual-kjerne P4/Xeon her, for Montecito har neppe særlig å stille opp mot mhp. lavere varmeproduksjon og strømforbruk enn f.eks dual-kjerne K8/PM.

Som det fremgår av teksten så er det Montecito han snakker om. Tro det eller ei. Selv har jeg sett den utviklingen i snart et år.

Når han sier "A lot of architectures are going to hit the wall (...) to heat and power dissipation" så snakker han tydeligvis om P4/Xeon, for disse har som kjent møtt veggen mhp. varmeproduksjon og strømforbruk. K8/PM har ikke møtt noen slik vegg ennå, åpenbart siden både varmeproduksjonen og strømforbruket er på vei ned.

Endret 15. november 2004 av snorreh

[Knick Knack]

Han snakker tydeligvis om dual-kjerne P4/Xeon her, for Montecito har neppe særlig å stille opp mot mhp. lavere varmeproduksjon og strømforbruk enn f.eks dual-kjerne K8/PM.

Som det fremgår av teksten så er det Montecito han snakker om. Tro det eller ei. Selv har jeg sett den utviklingen i snart et år.

Når han sier "A lot of architectures are going to hit the wall (...) to heat and power dissipation" så snakker han tydeligvis om P4/Xeon, for disse har som kjent møtt veggen mhp. varmeproduksjon og strømforbruk. K8/PM har ikke møtt noen slik vegg ennå, åpenbart siden både varmeproduksjonen og strømforbruket er på vei ned.

OK sånn å forstå. Da er jeg med. Tror imidlertid P-M og k8 er i ferd med å slippe opp for frekvens skalering. 90nm versjonene av k8 har ikke akkurat overbevist sånn sett ennå og de har nå vært ute en tid. Selv vanlig OC stopper ofte på 2.6GHz altså samme som 130nm k8. Da er liksom ikke 3.2GHz det jeg ser for meg med det første. Tror imidlertid de vil kunne levere nesten like raske dual core k8 som singel core k8. I allefall i begynnelsen. Så stikker vel singel core av noe i frekvens med tiden, men det er lite som tyder på at noen (selv AMD) forventer noe i nærheten av 200% ytelses økning for dual core.

Endret 15. november 2004 av Knick Knack

[snorreh]

OK sånn å forstå. Da er jeg med. Tror imidlertid P-M og k8 er i ferd med å slippe opp for frekvens skalering. 90nm versjonene av k8 har ikke akkurat overbevist sånn sett ennå og de har nå vært ute en tid. Selv vanlig OC stopper ofte på 2.6GHz altså samme som 130nm k8. Da er liksom ikke 3.2GHz det jeg ser for meg med det første. Tror imidlertid de vil kunne levere nesten like raske dual core k8 som singel core k8. I allefall i begynnelsen. Så stikker vel singel core av noe i frekvens med tiden,

Vi får se hva som skjer, men med 90nm reduserte AMD strømforbruket med minst 10% og kombinerer man dette med inkludering av "strained silicon" så er det fortsatt litt å gå på mhp. økning av frekvens tror jeg. Jeg har stor tro på 2. generasjons 90nm K8, "Lancaster", som skal redusere strømforbruket ytterligere (det er snakk om at den skal ha 25W TDP) og AMD sine Pacifica-prosessorer (K10?) som kommer i 2006/2007 skal bli enda mer strømgjerrige visstnok så jeg er fortsatt optimisk. Integrering av flere kjerner på prosessoren er forøvrig en fin måte å øke ytelsen på, heller det enn økning av frekvensen/strømforbruk/varmeproduksjon synes jeg.

 

men det er lite som tyder på at noen (selv AMD) forventer noe i nærheten av 200% ytelses økning for dual core.

AMD har bare uttalt seg om at de forventer 30-55% bedre ytelse på systemer med dual-kjerne prosessorer enn dagens dual-prosessor systemer:

AMD's dual-core performance boost

The size of the performance increase going to the new processor depends on the speed of the two chips. Comparing a computer today with one that uses two chip sockets with 90-nanometer processors, performance increases between 30 percent and 55 percent on various benchmarks, McGrath said.

Da gjenstår det bare å se hvem som får rett til slutt, og da tenker jeg ikke på Spec-tester

Endret 15. november 2004 av snorreh

[b0nna]

90nm skal vel få et par lag til og SS før den topper 3GHz.

Tror nok det er litt tidlig å konkludere noe om prosessen nå, eneste som teller for øyeblikket er volum.