AMD64 konkurrerer med Itanium

[pskard]

Det ville overraske meg veldig om jeg kunne vise til at IA64 hadde lavere latency enn Opteron også.

 

Ok, da er vi i det minste enige om at Itanium2 har høyere latency enn Opteron. Er vel i grunn vanskelig å diskutere ettersom IT2 har langt høyere latency.

 

Det har forøvrig ingenting med denne problemstillingen å gjøre. Alt handler om å håndtere det faktum at store mengder minne med høy båndbredde må ha høy delay med dagens CMOS teknologi.

 

Da er det et tankekort at et 4-veis Itanium2-system kun har den samme båndbredden som et singel P4-system (6.4 GB/s). Opteron derimot får bedre og bedre båndbredde ettersom en legger til CPU-er (25 GB/s på 4-veis, effektivt sett trolig 20 GB/s). I tillegg har den lavere latency ref over. Med andre ord ser det ikke ut til å stemme helt ennå. Alt peker motsatt vei i grunn. Det betyr selvsagt ikke at ting ikke kan endre seg.

 

IA64 backend jobber primært mot cache. Bare høyst unntaksvis direkte mot minnet, i motsetning til alle ISA'er jeg kjenner til.

 

Hva mener du med IA64 backend? Hvor mye CPU-en jobber mot cache vs minne kommer helt an på hva den utfører. Husk også at mer cache = dyrere CPU. Dyrere CPU = mindre salg. IT2 trenger en stor cache for å være effektiv (og det har den).

 

På den annen side skulle jeg gjerne sett at du kan vise til at IA64 vil skalere dårlig til dual core.

 

Det er selvsagt umulig å bevise da det ikke er noen på markedet. På samme måten som blir er umulig for deg å vise til at x86 (som er et ISA og ikke en arkitektur) vil "ta en del performance hits når den blir tvunget over på dual/multicore for å øke ytelsen. Dette i forhold til andre arkitekturer.".

 

Det som derimot er klart er at Opteron skalerer bedre enn IT2 (i alle fall opp til 4-veis). Mer vet vi ikke, da 8-veis IT2 ikke er testet og det finnes ikke 8-veis Opteron (ennå?). Opteron har også lavere latency som blir desto mer viktig når to cores (trolig) må dele* båndbredde mot minnet.

 

*Jeg antar at de må dele minneaksess da det vil muliggjøre å "dytte" en dualcore XEON i et hovedkort eller dualcore Opteron i sokkel 940. Om de skulle ha separate minnebusser måtte en øke pin-count på CPU. Det betyr ny package, nye hovedkort osv.

[Knick Knack]

Ok, du misstolket problemstillingen jeg fremsatte.

 

"Også fremtidige minne arkitekturer vil være plagsomme for x86 med sine høye delays."

 

Da tenker jeg ikke på dagens DDR I minne, men morgendagens DDR II og Rambus XDR minne som gir svært høye overføringshastigheter fra store moduler, men med høyere delay som en trade off. Delay til minne vil bli høyere (målt i cpu sykluser, ikke tid) uansett plattform siden den introduseres i RAM modulene og minnebuss protokollen. Utfordringen er å håndtere denne forsinkelsen, ikke å fjerne den, siden det er umulig. Siden programmer skrevet for IA64 har mulighet til å laste inn relevant informasjon fra RAM til cache før informasjonen kanskje kommer til nytte så vil prosessoren langt mer sjelden være henvist til å hente informasjon direkte fra RAM. Ta for eksempel en branch. Kompilator anser det f.eks. som overveiende sannsynlig at den ene grenen velges og laster den opp i L1, den andre grenen er mindre sannsynlig og blir lagt til L2 eller L3 mens CPU jobber med å finne ut hvilken branch som skal velges. For en vilkårlig x86 prosessor så vil det være langt mer tilfeldig hvor hver branch ligger. Derfor vil også gjennomsnittlig antall cpu sykluser som går med til idling bli større. Når en sammenligner gjennomsnittlig delay for en prosessor så er det viktig å regne fra backend ikke frontend som de fleste gjør.

 

(Hva som er front- og backend varierer litt fra hvilke bøker en leser. Ofte er cache med eventuelle load enheter (prefetch, speculative load,..) regnet som frontend og resten backend. Noen regner også med instruction decode i frontend, slik at backend blir strippet ned til de enhetene som gjør selve prosesseringen. Når en ser på delay og cpu idling så er det greiest å anta at cache med eventuelle load enheter er frontend og resten backend.)

[ØysteinI]

En multicore Opteron vil vel fungere mye likt som dual Xeon. Hvor CPUen får en minnekontroller (som tilsvarer Northbridge) med to innganger. Hver CPU får da i snitt halvparten av båndbredden som en single-core Opteron får, akkurat som dual Xeon bare får halvparten av båndbredden per CPU som en single Xeon.

 

For dual-core Xeon vil jo hver CPU igjen få halvert båndbredden, om Intel ikke legger fra seg Northbridge/Shared-FSB-"aritekturen ". Og om det ikke blir enda større cache'er, vil vel dette skalere ganske dårlig ?

[Knick Knack]

En multicore Opteron vil vel fungere mye likt som dual Xeon. Hvor CPUen får en minnekontroller (som tilsvarer Northbridge) med to innganger. Hver CPU får da i snitt halvparten av båndbredden som en single-core Opteron får, akkurat som dual Xeon bare får halvparten av båndbredden per CPU som en single Xeon.

 

For dual-core Xeon vil jo hver CPU igjen få halvert båndbredden, om Intel ikke legger fra seg Northbridge/Shared-FSB-"aritekturen ". Og om det ikke blir enda større cache'er, vil vel dette skalere ganske dårlig ?

Det ligger vel i kortene at en ønsker å øke minnebåndbredden med standarder som DDR II og XDR, slik at en kommer tilbake til multiplier nivå som var mer vanlige på P2 og P3 tiden. Altså effektivt 3X-4X multiplier i forhold til datarate. Da blir ikke båndbredde for 4-way FSB systemer like håpløs som den er nå, med effektiv multiplier på 5X-6X over datarate.

Endret 20. januar 2004 av Knick Knack

[pskard]

Ok, du misstolket problemstillingen jeg fremsatte.

 

Da tenker jeg ikke på dagens DDR I minne, men morgendagens DDR II og Rambus XDR minne som gir svært høye overføringshastigheter fra store moduler, men med høyere delay som en trade off. Delay til minne vil bli høyere (målt i cpu sykluser, ikke tid) uansett plattform siden den introduseres i RAM modulene og minnebuss protokollen. Utfordringen er å håndtere denne forsinkelsen, ikke å fjerne den, siden det er umulig. Siden programmer skrevet for IA64 har mulighet til å laste inn relevant informasjon fra RAM til cache før informasjonen kanskje kommer til nytte så vil prosessoren langt mer sjelden være henvist til å hente informasjon direkte fra RAM. Ta for eksempel en branch. Kompilator anser det f.eks. som overveiende sannsynlig at den ene grenen velges og laster den opp i L1, den andre grenen er mindre sannsynlig og blir lagt til L2 eller L3 mens CPU jobber med å finne ut hvilken branch som skal velges. For en vilkårlig x86 prosessor så vil det være langt mer tilfeldig hvor hver branch ligger. Derfor vil også gjennomsnittlig antall cpu sykluser som går med til idling bli større. Når en sammenligner gjennomsnittlig delay for en prosessor så er det viktig å regne fra backend ikke frontend som de fleste gjør.

 

(Hva som er front- og backend varierer litt fra hvilke bøker en leser. Ofte er cache med eventuelle load enheter (prefetch, speculative load,..) regnet som frontend og resten backend. Noen regner også med instruction decode i frontend, slik at backend blir strippet ned til de enhetene som gjør selve prosesseringen. Når en ser på delay og cpu idling så er det greiest å anta at cache med eventuelle load enheter er frontend og resten backend.)

Da missforstod jeg deg. Jeg er også helt med på skillet mellom frontend og backend i en cpu. Eller i alle fall at det er to deler av den (decode + execute).

 

Uansett synes jeg du overser et vesentlig poeng, og det er at dagens A64/Opteron har nok minnebåndbredde. Det burde tester av FX-51 vs 3400+ vise forholdsvis godt. Klart til enkelte oppgaver er det en fordel med mer båndbredde, men til det meste er forskjellen svært liten. En videre økninig fra 6.4 GB/s vil resultere i svært liten forbedring. Det samme gjelder P4. 6.4 GB/s er mer enn nok for den. "Problemet" til P4 er ikke båndbredde, men latency. Med DDRII vil latency øke enda mer. Heldigvis vil det for P4 motvirkes av at FSB, og derav minnekontroller, øker i hastighet. Trolig til 1066 MHz med 266 FSB QDR. Jeg er dog usikker på om det vil medføre noen merkbare forbedringer før en går over på DDRII 667 MHz med 333 FSB. Grunnen er den høye latencyen i DDRII.

 

Men, tilbake til poenget... Ettersom hverken P4 eller K8 har behov for mer rå båndbredde (til det meste) og latency er et langt større problem er det ikke sikkert overgangen til DDRII kommer til å komme så raskt. Når vi i tillegg tar med i beregningen at DDRII kommer til å bli dyrt, alt må byttes ut (hovedkort, cpu og minne) og det vil kun være små forbedringer (på kort sikt) vs DDRI kan det tyde på at vi kommer til å ha DDRI i en god stund fremover.

[snorreh]

Såvidt jeg vet så har AMD allerede tenkt på dette, og K8 skal være designet for å lett kunne implementere DDR2 og flerkjerneteknologi når det blir nødvendig.  Leste dette i et intervju med sjefsutvikleren til AMD en stund tilbake, men jeg finner ikke igjen linken nå dessverre så du får ta mitt ord for det

Joda, selvsagt har de tenkt på det. Jeg hadde en lengre samtale med AMD om dette i Dresden og i Cannes, og ble forsikret om at det ikke var noe problem.

 

Poenget er bare at selv om minnekontrolleren er laget som en helt egen del av die-en er det fortsatt vanskeligere å bytte over enn om det hadde vært en egen brikke som Intel bruker.

Ja, som det står litt om her:

http://www.ebnews.com/story/OEG20020709S0031

 

"AMD confirms that Hammer's on-die memory controller now supports only DDR-I, and that DDR-II will require a new Hammer chip design, at least for the memory portion. But the company claimed this was no big deal."

[b0nna]

Her http://www.realworldtech.com/forums/index....26178&roomID=11

er en spennende tråd.

Linus Torvalds har ikke særlig tro på Itanium.

[snorreh]

Her http://www.realworldtech.com/forums/index....26178&roomID=11

er en spennende tråd.

Linus Torvalds har ikke særlig tro på Itanium.

Ja, bra du fant den linken!

 

Jeg fant mange gullkorn fra ham der:

(IPF=Itanium Processor Family, x86-64=AMD64)

 

"The rest of the world doesn't care (about IPF) - they'll happily buy 32-bit chips if they are cheaper and perform better. Or if they buy 64-bit chips (may the day come soon when most people do so!), they'll happily buy them from other people than Intel, if the others can give them more bang for the buck.

 

And those others _do_ give that. Opteron gives a lot of bang, especially since "bang" is often about how well you run existing applications. IBM is doing a lot better with POWER than Intel is with IPF - with the 970 aka G5, IBM is even able to get on the desktop.

 

I suspect Intel has no choice but to go with the rumored "Yamhill" CPU. Exactly because IPF is getting shut out of the market. Mainly by good old x86."

 

&

 

"I'm arguing that the thing that killed alpha (and which is killing IPF) is _x86_."

 

&

 

"I was told the early Itanium machines at Microsoft all went to junior engineers because the senior people couldn't stand them. I don't know if that is true or not, but I don't find the notion in the least unbelievable."

 

&

 

"So I'm not claiming that the x86 is _beautiful_. It isn't.

 

But what it is, is 35 years of evolution and LISTENING TO CUSTOMERS. Instead of trying to foist something people don't want on them.

 

And the fact is, the end result is better for it. It may not be the most wonderful architecture in existence, but it is a pretty well-balanced chip that has an immense amount of widespread support.

 

And that's why I think the x86 is a _great_ architecture, and why I think AMD did the right thing with x86-64. Not because it is "beautiful". But because it is useful.

 

And in the end, I'll take useful over beautiful any day.

 

At least when it comes to computers."

 

100% enig med Linus Torvalds her!

Endret 4. juni 2004 av snorreh

[Knick Knack]

Linus har definitivt kommet opp med gode argumenter her. I motsetning til den sutringa han drev med tidligere. Har bare ett spørsmål:

 

Hvor mye dyrere er det greit at x86 PC'en er i 2010 i forhold til en EPIC basert maskin med samme ytelse?

 

Dobbelt så dyr? Fire ganger så dyr? Alle i bransjen vet at EPIC vil gi langt høyere ytelse enn x86 for den samme produksjonskostnaden over tid. Eneste argument for å holde seg til x86 er programvarekompatibilitet.

 

Saken er at før eller siden så må en bytte fra x86 til ett eller annet, og jo før jo mindre smerte blir det! Å håpe på at x86 skal holde helt til kvantemaskiner tar over er heller blåøyd.

Endret 21. januar 2004 av Knick Knack

[snorreh]

Har bare ett spørsmål:

 

Hvor mye dyrere er det greit at x86 PC'en er i 2010 i forhold til en EPIC basert maskin med samme ytelse?

 

Dobbelt så dyr? Fire ganger så dyr? Alle i bransjen vet at EPIC vil gi langt høyere ytelse enn x86 for den samme produksjonskostnaden over tid. Eneste argument for å holde seg til x86 er programvarekompatibilitet.

 

Saken er at før eller siden så må en bytte fra x86 til ett eller annet, og jo før jo mindre smerte blir det! Å håpe på at x86 skal holde helt til kvantemaskiner tar over er heller blåøyd.

Du både stiller spørsmålet og svarer på det selv?

 

Hvilke produkter og priser vi har i 2010 blir helt hypotetisk, veldig mye kan endre seg innen den tid. Hvis jeg får lov å spekulere så lever nok x86-64 PC'en i beste velgående også da, trolig i en helt integrert løsning (a'la UMA). Jeg ser ingen indikatorer på at EPIC (les: IA64) kommer til å koste mindre enn x86 med det aller første, snarere tvert i mot da Intel planlegger å øke cache ytterligere noe som medfører ytterligere prisøkning iforhold til x86. Per i dag så er x86 mest konkurransedyktig, og det er det eneste som teller i databransjen.

 

Jeg stiller meg også svært skeptisk til din påstand om at "alle i bransjen vet at EPIC vil gi langt høyere ytelse enn x86 for den samme produksjonskostnaden over tid". Hvor tar du dette fra egentlig?!

Endret 21. januar 2004 av snorreh

[pskard]

I tillegg er det nå enn slik at x86 har kommet mye lengre enn det "alle i bransjen" trodde den ville. F.eks. er introduksjonen av AMD64 er godt eksempel og at PC prosessorer i dag er de raskeste på markedet. Eksempler på at en ikke bastant burde si at "dette er dårlig" e.l.

 

Det er vel noe utsagt a la dette tidligere som 640 KB.... osv. Det viser seg fort at ting utivikler seg og endrer seg over tid. I tillegg er det nå enn slik at det ikke nødvendigvis er den beste standarden som vinner. Når Intel lanserer støtte for AMD64 (eller x86-64 kall det hva du vil) betyr det også at IA64 vil få en tungt slag.

 

Jeg er også spent på å høre hvorfor ytelse på Itanium skal være så mye rimeligere å lage enn på x86-chips. Så langt ser vi i alle fall at Itanium2 er svært dyr å produsere. I tillegg skalerer Opteron bedre i SMP og MHz.

[Knick Knack]

Edit: Håper denne posten balanserer seg såpas bra ut mot slutten at det er mulig å nikke litt forsiktig på hodet til mye av det som står her. Det var i alle fall meningen.

---------------------------------------------------------------------------------

 

Dere har forsåvidt rett. En skal aldri si aldri. Alt tyder imidlertid på at x86 har hentet ut det som er å hente ut av de superskalare arkitekturene en benytter i dag. Utvidelse av både Netburst og K8 har vist seg å gi N^2 økning av kompleksitet, så en begynner å bli henvist til å implementere flerkjerne arkitekturer samt øking av frekvens som eneste fremdrift. Denne N^2 effekten er også grunnen til at x86-64 kun har 16 generalpurpose registre. Det er mulig at x86 vil bli ført over på en static-scalar (også kjent som VLIW) arkitektur i fremtiden, da denne typen arkitektur utnytter økt transistor antall langt mer effektivt enn superscalare arkitekturer. Denne trenden har vist seg lenge. Først var RISC best, så ble brikkene mer komplekse og RISC ble utspilt fordi den ikke maktet å utnytte kompleksiteten i brikkene. CISC kunne fint utnytte denne kompleksiteten og tok over. Nå er vi kommet til det punkt at utvidelse at CISC på superscalar arkitektur stanger i loven om diminishing returns ved øking av antall transistorer/chip. Static-scalar står klar til å ta over. Efficeon er vel første (?) eksempel på x86 implementert på VLIW/ Static-scalar. Skulle ikke overraske meg om Nehalem også blir en VLIW variant.

 

Argumentet om at Opteron skalerer bra til SMP er ikke viktig for fremtidig utvikling. Grunnen til at Opteron skalerer bra har ingen ting med x86 å gjøre, kun det faktum at den benytter et EV7 basert maskenett for intern kommunikasjon. Det kan alle arkitekturer utvides til å benytte, men denne løsningen er heller ikke feilfri og den ser ut til å gradvis miste sin ene store fordel (lav delay i minnekontroller), med introduksjon av neste generasjon minne siden delay blir flyttet ut av minnekontroller og over på RAM modulene og minnebuss protokollen.

 

Selv om den interne minnekontrolleren alltid vil gi litt bedre delay enn en chipset løsning, på 1 og 2-way, så er dette fremfor alt en løsning som er i vinden nå pga. unormalt høye multipliere på prosessorene. Når disse multiplierene blir senket med høyere minnebuss hastigheter så vil fordelen av denne EV7 bussen marginaliseres for alle N-way systemer, og særlig for 4+-way. Årsaken er throughput computing prinsipper som gjør prosessorene mindre følsomme for delay, redusert kollisjons frekvens (grunnet lavere multiplier) gir FSB samme delay som maskenett på 4-way og store mengder relativt billig cache (off-die, on-module i MB->GB størrelsen med direkte chip/chip interconnects) bidrar til effektivisering av throughput computing, gitt at en utnytter cache rimelig godt. Det klarer ikke x86 siden den kun har hw/runtime algoritmer å støtte seg til. EPIC har hw/runtime OG sw/compiltime algoritmer til å avgjøre hva som skal ligge i hvilken cache og når.

 

Hvis dere mot formodning skulle være med på at x86 må over på static-scalar for å utnytte høyere transistor antall, så er regnestykket enkelt. EPIC = x86 - "masse skrot". Er en ikke med på denne tankegangen så får det bare være. Superscalar er ved veis ende ved Tejas for Intels vedkommende. Årsaken er nevnte, og i litteraturen veldokumenterte, N^2 kompleksitet, hvilket vil si at ytelsen begynner å skalere med kvadratroten av transistorantallet.

 

Egentlig er det en "no-brainer" å forklare hvorfor EPIC er mer effektivt enn x86. Årsakene er bare så ekstremt opplagte og mange. Jeg anbefaler at de som måtte få lyst til å dissekrere denne posten først leser seg opp på superscalar og EPIC/VLIW (likheter og forskjeller) før en haster i vei. Det har nemlig jeg gjort. Gå for seriøs litteratur (bøker ment for undervisning), ikke slike tvilsomme forumposter (som denne? ). Det er minst like mye propaganda i de foruminleggene som er å lese rundt om på nettet som det er i Intels markedsførings slides.

Dette er vel etter min mening det mest seriøse jeg funnet på nettet:http://arstechnica.com/cpu/index.html

 

Til slutt det aller viktigste:

 

Det er slik jeg ser det ca 50/50 sjanse for at hhv. EPIC/x86-64 går av med "seieren". EPIC er "best", men det betyr slettes ikke at den vinner. Uansett hva som vinner så blir det før eller siden omkamp mot fremtidige standarder. Blir det x86-64 som vinner, så kommer vel omkampen snarere før enn siden. Da antagelig mot MAC/IBM power som allerede har et godt grep om x86 ytelsesmessig. Litt ironisk at IBM power er RISC. Sukseen skyldes blandt annet at trenden med lange pipelines har begynt å favorisere RISC igjen. Det er da heller ikke det verste som kan skje. Vinner EPIC så er det mindre sannsynlig at en får en omkamp med det første, siden EPIC er langt mer moderne og bygger på kunnskap en har tilegnet seg helt frem til 90-tallet, samt tar hensyn til at fremtidige minnearkitekturer vil måtte ha høy delay og at denne ikke ligger i minnekontrolleren. Det vil ta noe tid før en klarer å komme opp med en standard som er så mye bedre enn EPIC at det rettferdiggjør et skifte. Det er jo et relevant diskusjons tema om/når EPIC fyller disse kravene ovenfor x86!

 

Mange spåmenn tror den standarden som klarer å ta over for x86 blir stående frem til kvantemaskiner tar over. Andre spåmenn tror x86 kommer til å vare "evig", jeg tror disse tar like feil som de som spådde at x86 kom til å dø etter i486. Jeg tror ikke x86 kommer til å dø brått, men bokstavelig talt bli slått på hjemmebane i en seig kamp. Nemlig med Intel som promotor og pris/ytelse som argumentasjon. At EPIC prosessorer vil bli dyre grunnet masse on-die cache er en myte som skyldes at de fleste EPIC (IA64) prosessorer som er på markedet er rettet mot highend servere, hvor 144MB on-module cache ikke er en usannsynlig kombo. IA64 har imidlertid delt seg i to reninger, med en workstation linje som foreløpig er frekvens begrenset for ikke å konkurere med server linja. Det en ser av EPIC nå, altså IA64, er bare de første ustø skrittene til et barn som har plan om å bli noe stort. x86 er en mann i sin beste alder, ingen grunn til å forvente store forbedringer her. Mao. fare for generasjonsskifte. Største faren for at det ikke blir noe skifte er at forbrukerne ser seg fornøyd med x86 sin pris/ytelse og tar seg derfor ikke det ekstra bryet med å skifte plattform. Time Will show. Som teknolog er jo favoritten klar; EPIC (har ingen ting med Intel å gjøre, IBM er min "favoritt" i så måte). Vi drar ikke til Mars og Månen fordi det så enkelt eller med håp om kortsiktig økonomisk besparelse, vi drar dit fordi vi ønsker å flytte grenser.

Endret 22. januar 2004 av Knick Knack

[snorreh]

Ace's Hardware har en meget interessant artikkel om hvordan ta knekken på x86:

http://www.aceshardware.com/read.jsp?id=60000308

 

[Knick Knack]

Ace's Hardware har en meget interessant artikkel om hvordan ta knekken på x86:

http://www.aceshardware.com/read.jsp?id=60000308

 

Leste den i går. Meget interessant, men jeg ble ikke akkurat overbevist av det "i64" prosjektet heller.

[snorreh]

Ace's Hardware har en meget interessant artikkel om hvordan ta knekken på x86:

http://www.aceshardware.com/read.jsp?id=60000308

 

Leste den i går. Meget interessant, men jeg ble ikke akkurat overbevist av det "i64" prosjektet heller.

i64-forslaget var jo rent hypotetisk da, altså noe Intel kunne ha gjort dersom de virkelig var interessert i å kvitte seg med x86 til fordel for Itanium. Etterom Intel ikke har gjort noe som helst i den retningen så da kan man begynne å lure på hvor seriøse de egentlig er i forhold til at Itanium skal bli arvtageren til dagens x86.

 

Jeg synes Chris Rijk kommer med noen meget gode poenger, bl.a. disse gullkornene som jeg har tatt meg friheten til å summere opp:

 

"Intel chose the most radical route - a completely new instruction set with a relatively unproven architecture style (VLIW), which would also ship along side x86 systems for some time. AMD, and most of the RISC vendors, chose the least radical route - to extend their existing 32-bit architectures to 64-bits, while improving the performance of existing 32-bit code."

 

"The HPC market is an exception, as customers roll their own code, and are far more price and performance sensitive than the market in general. Despite Itanium's success in the HPC market, there are reports of HPC systems being given away, which is quite surprising."

 

"The Itanium also needs new or heavily changed compilers and compilers always have bugs, and to make matters worse, the Itanium is far more dependent on compilers than other CPUs. Overall, this makes it riskier for early adopters and work harder for ISVs - many of whom are saying "we might support Itanium next year" in a kind of "tomorrow never comes" way."

 

"Intel's VLIW-style instruction set for Itanium could be seen as a "next generation" attempt to re-simplify core designs again - to make implementing complex super-scaler designs easier. But even the efficiency dependent embedded CPUs and DSP markets make little use of VLIW, and instead multi-core multi-threaded designs are being used for the most demanding tasks, and RISC-style designs dominate the whole embedded market."

 

"Apple managed a careful transition to the PowerPC architecture, also from the 68000, with effective backwards compatibility, over a period of years. Apple and Sun were helped by the fact that they do the OS and system design themselves, something Intel doesn't have with Itanium - it's easier for systems companies to migrate because they directly control more of their market. DEC tried to migrate their installed base to Alpha, but despite popular acclaim and success in the HPC market, this has ended in failure."

 

"For the CPU design itself, it (Itanium) seems rather too complicated (instruction set is very hard to understand making development and debugging difficult), and developing good compilers for it is very difficult. Intel should have also put more effort into getting fast, stable compilers out earlier, to help ISVs and help customers, some of whom have had some difficulty in getting the best performance out of their Itanium systems."

 

"An essential problem for Intel is that it's very unlikely that Itanium will become clearly successful quickly, and meanwhile their competitors do not share the same conversion problems and are upgrading their technology at a decent rate. Though Intel has the financial might to keep on trying for a long time, they can't afford for the market to run away from them. You could say it would be better for Intel if Itanium failed quickly rather than a long drawn-out battle of partial successes. So, what happens if Intel is forced to drop Itanium? The biggest loser would be HP, whose enterprise division are dependent on converting PA-RISC customers to Itanium - this would probably leave only IBM and Sun in the market for what is currently 8-way and higher servers."

 

"If Itanium fails, it's almost certain Opteron would be in good shape, so this last point is significant. Currently, the smart money is on Intel doing an AMD64 capable version of the Pentium 4 in early 2005. Of course, Intel will be working hard to ensure Opteron "fails" and Itanium "succeeds"."

 

"With Itanium, almost all the problems have been strategic - if Itanium fails, it will likely be labeled as the biggest strategic mistake in computing history."

 

100% enig!

 

P.S. Merk at EPIC ikke ble nevnt med et eneste ord i hele artikkelen, bare referert til som VLIW

Endret 24. januar 2004 av snorreh

[Knick Knack]

P.S. Merk at EPIC ikke ble nevnt med et eneste ord i hele artikkelen, bare referert til som VLIW

Sier vel litt om hvor lite denne fyren vet om IA64 og EPIC. Forskjellene på tradisjonell VLIW og EPIC er ikke mange, men viktige. F.eks. er det mulig å kjøre all EPIC kode på en hvilken som helst EPIC prosessor uten å rekompilere koden. Det er ikke mulig med vanlig VLIW og var da også et av de største problemene med denne typen arkitektur.

[Knick Knack]

Fant følgende reaksjon på artikelen på Aces:

 

> It wouldn't be with VLIW, I think HP and Intel blew their

> chance with the Itanium. They forgot one very important

> thing... software. I would have chosen a new CISC ISA,

> something compiler designers and software folk would feel

> comfortable with. The task of porting software needs to

> be as painless as possible or it won't happen.

 

CISC? Are the important lessons of Cocke, Hennessy, and

Patterson etc so easily forgotten by a new generation? The

concerns of compiler writers were only taken seriously in

post-CISC architectures (RISC/EPIC). Name one CISC ISA

developed since the early 1980s (AMD64 is an extension of

an existing 26 year old CISC ISA).

 

CISC er og blir et assembler rettet ISA. Kompilatorer makter ikke å utnytte CISC slik de kan med RISC og EPIC/VLIW. Siden høynivå koding i f.eks Java er blitt populært så begynner også svært mye av kodebasen å bli uavhengig av x86. Mao. trumfkortet til x86 brenner.

[snorreh]

Knick Knack: Når du siterer noe, så hadde det vært greit om du henviste til kilden...

 

Svar på denne påstanden finner du her:

http://www.aceshardware.com/forum?read=105066626

 

"I would go re-read the text. The complier writers that I know hate IA64. Yes, it is possible to optimized code until it runs well, but your compile times are so high that only tiny apps would be built with those settings. You have to spend alot more time optimizing IA64 to get the same perf as x86. Then consider that alot of code is moving into bytecode. Jitters do not have the luxury of spending alot of time optimizing the code.

 

Also VLIW instructions are easy on the decoder, but Intel and AMD can make fast x86 decoders. In turn VLIW instructions waste cache, memory and bandwidth. The world would be better off if IA64 died and Intel adopted AMD's extensions to x86."

 

Litt mer om CISC/EPIC her:

http://www.aceshardware.com/forum?read=105066295

 

"CISC is an optimization for code size, RISC is an optimization for decoder efficiency. EPIC is an instruction set to allow an in order instruction core to perform as well as an out of order core by placing the burden of identifing what can be run in parallel on the compiler.

 

While it is true that some CISC archtectures like the VAX went overboard and caused endless decoder problems, x86 has never had those problems.

 

Increasingly code size is becoming important again. Both to reduce costs and as a way to increase performance. Performance is increased if you need to read in less data into your icache before you can execute code, and you can hold more code in your second level cache.

 

So given that a good replacement for x86 would be a clean CISC architecture with a register file just large enough to express code with out register spills. Register renaming is sufficient for the rest of the cases anyway.

 

I think I would do something very much like AMD has done.

 

You could be a little more orthogonal and a little cleaner. But when even embedded RISC cpus are becoming CISC I don't see the point in avoiding it. "

 

Itanic mistakes

http://www.aceshardware.com/forum?read=105066382

 

"While I agree that going with the untested VLIW concept was a mistake (mainly in that it helped make Merced very late), IA64 suffered more from marketing/product positioning mistakes.

 

1. Intel and HP overestimated the technical effects of a decent ISA. Both Intel and AMD have done an amazing job of getting performance out of that crappy old x86 ISA. The system architecture (memory, I/O), which has very little to do with the ISA, has become an increasingly important aspect of system performance. The Opteron architecture goes a lot further towards solving these system architecture problems than the fairly ordinary Itanium system architecture.

 

2. Rather than push up from the high-volume home market, Intel decided to start with a low-volume, expensive, server processor. This eliminated Intel's manufacturing advantage which allows it to produce a lot of processors cheaply. So far, Intel hasn't given anyone a reason to buy Itanium. Currently, the value of an Itanium system is not very compelling. Whatever solution Intel produced should have been pushed up from the home market rather than down from the high-end server market."

 

Glimrende sagt!

 

Som vanlig mange spennende diskusjoner på Ace's Hardware sitt forum.

Endret 26. januar 2004 av snorreh

[Knick Knack]

Jeg lot være å poste svaret på det sitatet jeg postet siden det var av elendig kvalitet. "The complier writers that I know hate IA64" (LOL?) Det de fleste motstanderne av IA64 gjør feil er å se på de barnesykdomene arkitekturen sliter med nå, som en generell trend. Utviklingsverktøyene til IA64 er naturlig nok svært uferdige i forhold til x86.

 

"In turn VLIW instructions waste cache, memory and bandwidth" Relativ påstand, og ikke er det ventet å bli en flaskehals heller. Cache er ikke noe problem per i dag og vil bli mindre problematisk med tiden, minne får en slengt etter seg i hauger til lave kostnader relativt til systemene. Bandwidth er et typisk 2003-04 problem som oppsto fordi RDRAM ble skvisa av minneindustrien til fordel for langt dårligere DDR SDRAM. DDR 2 vil rette opp dette innen 2005. Har forøvrig ikke hørt rykter om når IPF vil få høyere FSB, men før eller siden må det skje.

 

Forøvrig er det en tommelfinger regel at 90% av CPU-tid ligger i 10% av koden. Det er derfor tanken å holde denne CPU intensive delen av koden i cache (noe som er ideelt uansett arkitektur) Dermed vil heller ikke båndbreddebehovet bli særlig øket i forhold til x86 siden data utgjør en større del av overføringene. Det skal også sies at IA64 kode er lagd slik at den utnytter båndbredden mye bedre enn x86. Altså vil et IA64 system med 6.4GBps max ha høyere effektiv båndbredde enn et x86 system med 6.4GBps max.

 

Itanic mistakes

http://www.aceshardware.com/forum?read=105066382

 

(..)

 

Denne hadde gode poenger, men ser du, IO/minne systemet er ikke så ille som folk skal ha det til. (Har en behov for IA64 med svært høy BW så er SGI Altix et alternativ.) Det var dessuten en fornuftig løsning å benytte FSB når en introduserer en ny arkitektur siden den er godt testet. Mhp. punkt 2 så er det vel godt mulig Intel vil redusere prisen på low end 90nm IA64 systemer siden disse vil få dies som er innenfor den størrelsen Intel er best på.

Endret 26. januar 2004 av Knick Knack

[pskard]

En av de tingene jeg synes er skremmende med IT2 er at ingen får "lov" til å teste den. Se på det enorme antall tester av XEON og Opteron og hvor få som har testet IT2..

 

Intel kan si, så mye de bare vil, at IT2 og XEON/Opteron ikke er i samme liga, men det vet vi ikke stemmer i realiteten. Vi trenger ikke å se lengre enn Top500 e.l. for å få bekreftet at "Big Tin"-bokser også er laget av XEON, MP og Opteron. Da er det skremmende hvor stor manglen av objektive tester er.

 

En kan selvsagt lure på hvorfor Intel er så tilbakeholdene med å la noen testen IT2.