AMD64 konkurrerer med Itanium

[DesertGlow]

pg: Please ikke start den pipeline greia igjen. Ja jeg har påstått at lengre pipeline kan medføre bedre ytelse (IPC), men det var altså med henvisning til et tilfelle som ikke er gyldig for NW->Prescott overgangen. Lengre pipeline kan forøvrig øke IPC dramatisk i enkelte tilfeller (flere hundre prosent), men det er et tilfelle jeg ikke har trengt å forklare nærmere her.

 

Den opprinnelige diskusjonen var vel hva som ville skje om Prescott ville få 22 steg pipeline, og flertallet av de aktive deltagerne mente at dette ville isolert sett gi ca 10% dårligere ytelse. Nå har vi sett fasiten. Prescott fikk 55% lengre pipeline og opp mot dobbel delay til L1 og L2 cache i forhold til NW. Med flertallets argumentasjon så skulle 55% lengre pipeline resultere i en redusert ytelse på 30% (eller.no rett meg gjerne, det er faulty logic uansett).Dette baserer seg på den umulige hendelsen at alle instruksjoner er en branch som får misspredict med L1 cachehit som resultat. Ikke bare er dette en umulig hendelse, den er også langt fra de faktiske forhold. Dette ble mye teknisk og det er ikke et forsøk på å virke proff (som jeg faktisk har blitt beskyldt for), men det er faktisk sånn at dette er tekniske greier ok?

 

Nå kunne jeg kjørt en lang konklusjon her, men det gidder jeg ikke dere som vil kan finne en av de mange jeg allerede har skrevet.

 

Og ja pg. helt til slutt. det er riktig at lengre pipelines (i P4 tilfellet) medfører redusert IPC, men jeg har altså argumentert for at denne ikke nødvendigvis er vesentlig. Og ikke i nærheten av de estimatene som er blitt foreslått her på forumet. Ser du tilbake på argumentasjonen som er ført i denne lange diskusjonen så vil du se at jeg fortsatt klarer å forsvare påstander som er rimelig i samsvar med det jeg først påsto, mens "motparten" har vinglet kraftig og har måttet trekke vesentlige deler av argumentasjonen.

Må bare kaste inn at grunnen til at ytelsestapet på Prescott ikke ble på 30% i forhold til NW er fordi Intel etter beste evne har lagt inn teknologier som gjør at ytelsestapet blir mindre. Bedre branchprediction og dobbel L2-cache prøver i stor grad å utligne de 55% lengre pipelinene.

 

Det er vel hevet over enhver tvil at lengere pipelines isolert sett fører til lavere IPC under normal bruk. Vanskligere er det egentlig ikke. At det i forutsigbare operasjoner kan gi langt bedre ytelse fordi man i større grad kan presse klokkefrekvensen er også et faktum.

 

Det var vel Anandtech som så fint uttalte at "alle disse forbedringene i Prescott høres kanskje ut som noe som vi gi drastisk mye bedre ytelse, men husk at mestepraten av dette kun er for å veie opp for lengere pipelines" (eller noe i den duren, lenge siden jeg leste det nå).

[Knick Knack]

Må bare kaste inn at grunnen til at ytelsestapet på Prescott ikke ble på 30% i forhold til NW er fordi Intel etter beste evne har lagt inn teknologier som gjør at ytelsestapet blir mindre. Bedre branchprediction og dobbel L2-cache prøver i stor grad å utligne de 55% lengre pipelinene.

Litt "pirk" her: Endringene er ikke _grunnen_, men medvirkende årsak til at IPC ikke reduseres så mye. 30% dårligere IPC er et tall hentet ut fra ingensteds, og er basert på en feilsluttning kommentert i forige post.

 

Håper forøvrig alle her innser at om det ikke hadde vært på branch misspredicts så ville ikke pipelinelengden påvirket IPC. Det er helt grunnleggende å forstå det!

[b0nna]

In the beginning IPF was supposed to replace IA32 by 1999. But P4 Performance/clock projections killed that idea.

 

edit link som funker:

http://stanford-online.stanford.edu/course...8-ee380-100.asx

Denne er med

"Bob Colwell was Chief Architect of Intel's IA32 microprocessors

from 1992-2000, and managed the IA32 Arch group in Intel's Hillsboro, Oregon facility. Colwell joined Intel in 1990 as a Senior CPU Architect on the P6 (Pentium Pro) project, and became manager of the Architecture Group two years later. He was named an Intel Fellow in 1996, the highest technical grade at the company."

 

Er MUST see.

"I mean, he lead the P4 development, and simply admitted the high clock speed was a "blue chrystal" marketing trick, and they tried their best to extract reasonable performance/IPC from it nevertheless."

Endret 22. februar 2004 av b0nna

[pskard]

Den opprinnelige diskusjonen var vel hva som ville skje om Prescott ville få 22 steg pipeline, og flertallet av de aktive deltagerne mente at dette ville isolert sett gi ca 10% dårligere ytelse. Nå har vi sett fasiten. Prescott fikk 55% lengre pipeline og opp mot dobbel delay til L1 og L2 cache i forhold til NW. Med flertallets argumentasjon så skulle 55% lengre pipeline resultere i en redusert ytelse på 30% (eller.no rett meg gjerne, det er faulty logic uansett).

 

 

Les tråden igjen så ser du at det ble sagt var at 2 ekstra steg i pipelinen (20 til 22 steg) vil medføre en 10% høyere BRANCH-kostnad (mispredict). Hvor mye det slår ut på ytelse kommer helt an på hvor ofte CPU-en har branch mispredict.

 

Da antar jeg at vi har avklart "pipelinemyten" en gang for alle. Lengre pipeline medfører lavere IPC.

Endret 22. februar 2004 av pgressum

[Knick Knack]

Den opprinnelige diskusjonen var vel hva som ville skje om Prescott ville få 22 steg pipeline, og flertallet av de aktive deltagerne mente at dette ville isolert sett gi ca 10% dårligere ytelse. Nå har vi sett fasiten. Prescott fikk 55% lengre pipeline og opp mot dobbel delay til L1 og L2 cache i forhold til NW. Med flertallets argumentasjon så skulle 55% lengre pipeline resultere i en redusert ytelse på 30% (eller.no rett meg gjerne, det er faulty logic uansett).

 

 

Les tråden igjen så ser du at det ble sagt var at 2 ekstra steg i pipelinen (20 til 22 steg) vil medføre en 10% høyere BRANCH-kostnad (mispredict). Hvor mye det slår ut på ytelse kommer helt an på hvor ofte CPU-en har branch mispredict.

 

Da antar jeg at vi har avklart "pipelinemyten" en gang for alle. Lengre pipeline medfører lavere IPC.

Jeg har aldri kranglet på utregningsmetoden du benytter her. Det var faktisk jeg som introduserte den etter at de fleste andre hadde satt seg godt fast på limpinnen. Dette var rundt desember?

 

Så ja! lengre pipeline medfører lavere IPC (annslått 0.5% for 10% lengre pipeline i dette tilfellet, som må være for et program med mange trassige branches.)

 

I dette lyset blir det vel ikke så rart at jeg innførte begrepet pipelinemyten om de fantastiske annslagene som tilsa 10% lengre pipeline medfører 9-10% (dere lå der omkring på det værste) dårligere ytelse. Hadde det ikke vært for den ekstreme staheten rundt dette så hadde vi vært i mål et par hundre poster tidligere.

 

Det gleder meg selvsagt at jeg hadde rett från børjan av! Om jeg skulle ha lest feil i argumentasjonen til noen i denne tråden så er jo det leit og det beklager jeg. Det har seg sånn at denne pipeline greia har rast rundt i flere tråder de siste månedene så jeg skummer av og til litt kjapt gjennom poster fra folk jeg vet har satt seg fast i sin egen oppfatning av sannheten.

 

Edit: hvorfor fjerna du det geniale eksempelet?

 

la meg gjenta ca hva du originalt skrev:

 

Vi anntar 95% predicted og 10% lengre pipeline og får. 5%*10%= 0.5% tapt IPC

Endret 22. februar 2004 av Knick Knack

[DesertGlow]

Må bare kaste inn at grunnen til at ytelsestapet på Prescott ikke ble på 30% i forhold til NW er fordi Intel etter beste evne har lagt inn teknologier som gjør at ytelsestapet blir mindre. Bedre branchprediction og dobbel L2-cache prøver i stor grad å utligne de 55% lengre pipelinene.

Litt "pirk" her: Endringene er ikke _grunnen_, men medvirkende årsak til at IPC ikke reduseres så mye. 30% dårligere IPC er et tall hentet ut fra ingensteds, og er basert på en feilsluttning kommentert i forige post.

 

Håper forøvrig alle her innser at om det ikke hadde vært på branch misspredicts så ville ikke pipelinelengden påvirket IPC. Det er helt grunnleggende å forstå det!

Yepp, der er vi enig. Ville man til en hver tid kunne fylle opp alle stegene i prosessorene så kunne man uten problemer hatt 100 steg (hvis man skulle finne en måte å utnytte dette).

 

Når det gjelder de 30% så det nevnes her så har jeg ikke regnet på det, men det er nok ikke så veldig langt fra sannheten, men det kommer selvsagt veldig ann på hva slags type programmer man bruker.

 

Jeg tror forøvrig økningen av cache-størrelsen fra 512 kB til 1 MB ble lagt inn for å minke "straffen" ved missprediction. Det er snakk om rundt 20% større die, som betyr ganske mye når man tenker på antall kjerner per wafer, og det legger man ikke inn med mindre man må. Derimot forbedringen av branch-prediction er vel trolig noe de hadde gjort uansett.

[pskard]

Knikk Knakk: Det jeg skrev er det jeg, Simen1, Snorreh m.fl. har argumentert for hele tiden. Du har stanhaftig argumentert for at det var feil. Evt får du lese over trådene en gang til. Hvor du får det fra at dette er noe du kom med skjønner jeg ikke.

 

F.eks. kan jeg vise til denne posten din:

 

Siden pipeline er 55% lengre kan vi gjøre litt blunt matte, som vil gi et overslag på hvor mye selve pipeline forlengelsen utgjør i IPC tap: 55%*0.75%= 0.4% Altså 0.4% lavere IPC pga 55% lengre pipeline! (Edit: dette i forhold til "NW II") Det som hemmer Prescott er den doble forsinkelsen til L1 og L2 cache.

 

Pipeline myten lenge leve...

 

Her vil jeg påstå at det kommer forholdsvis godt frem at du ikke er enig i at lengre pipelines gav dårligere ytelse (teoretiske 0,4% lavere IPC ved 55% lengre pipelines er ikke noe å snakke om).

 

pipeline myten enda lengre leve... nå med ny og 55% lengre smak.

http://forum.hardware.no/index.php?showtopic=203217&st=60

 

Kunne sikkert funnet en rekke andre eksempler på det, men orker ikke å lete etter det. Ser i grunn ikke noe poeng heller ettersom vi til slutt har blitt enige.

 

Jeg tok vekk "det geniale" eksemplet fordi det var noe missvisende/feil (det som står igjen stemmer). Hvorfor det var missvisende/feil er fordi vi ikke vet hva kostnaden for en mispredict (spesielt ettersom Intel skal ha lagt inn logikk for å redusere kostnaden på en mispredict på prescott). Derfor kan vi ikke si at 10% høyere mispredict-kostnad fører til (i dette tilfellet) 0,5% lavere ytelse, men vi kan si at kostnaden for mispredict går opp. I alle fall er ytelseskostnaden ved mispredict ukjent for meg.

Endret 22. februar 2004 av pgressum

[snorreh]

Slettet

Endret 23. februar 2004 av snorreh

[b0nna]

In the beginning IPF was supposed to replace IA32 by 1999. But P4 Performance/clock projections killed that idea.

 

http://stanford-online.stanford.edu/course...8-ee380-100.asx

Linken virket ikke, men det gjør denne:

http://stanford-online.stanford.edu/course...7-ee380-100.asx

 

Interessant

Den der er med AMD fyren, i innlegget du siterte som jeg nå har redigert finner man ex intel arkitekten.

[Knick Knack]

pg: Her møtte du deg selv i døra så det smalt! De tallene du viser til er akkurat samme regneprinsippet som et skjermbilde lengre oppe. samme type formel som du selv presenterte og fjernet i en edit. Forskjellen er forholdstallene. De vil naturlig nok endres med programmene en kjører. Flere branches større tap!

[pskard]

pg: Her møtte du deg selv i døra så det smalt! De tallene du viser til er akkurat samme regneprinsippet som et skjermbilde lengre oppe. samme type formel som du selv presenterte og fjernet i en edit. Forskjellen er forholdstallene. De vil naturlig nok endres med programmene en kjører. Flere branches større tap!

Knikk Knakk: Fint at du endelig har blitt enig i dette, men les over trådene en gang til så ser du hva du har hevdet hele tiden. Jeg gidder ikke lete gjennom alle postene, da vi veldig godt vet hva du har sagt. Konstanterer at du har endret standpunkt og det er bra . Regner også med at vi slipper mere "pipelinemyten"-kommentarer fra deg nå.

 

 

PS: Eksemplet du tok opp er fortsatt skrekkelig feil.

[Knick Knack]

Hva om du legger frem en selvstendig post (altså uten henvisninger til andre tråder/poster) som beskriver "anntat IPC tap direkte relatert til lengre pipeline". Om du velger å uttrykke det som branch tap eller totalt tap er samma for meg. Så kan vi se hvor enige/uenige vi er.

 

Finner det pussig at du mener jeg har endret oppfatning OG er enig med deg! Høres ut som et desperat forsøk på å redde ansikt.

 

Edit: Og når vi er ferdige med branches så kan vi altids begynne med loads og hjerneknuseren; hvilken del av pipeline ble endret kontra når er "target pranch address" tilgjengelig og når er branch kondition tilgjengelig. Alt dette skjer nemlig et godt stykke før slutten av pipen.

Endret 23. februar 2004 av Knick Knack

[pskard]

Dette er ting du har skrevet Knikk Knakk:

Skrevet: 22/01/2004 : 11:51

Er snakk om 2 steg lengre, men jeg vet ikke hvor mye som er bekreftet. Lengre pipeline er forøvrig ikke ensbetydende med lavere IPC.

SNIP

Selv om noe tror motsatt...

 

 

Skrevet: 02/02/2004 : 10:30

Prescott er om ikke annet et bevis på at "longer pipeline" myten ikke medfører riktighet.

 

 

 

Skrevet: 02/02/2004 : 11:15

"Dette viser at du har tatt feil hele tiden med dine påstander som at desto lengre pipeline desto bedre IPC" WTF? Jeg sier lengre pipeline ikke nødvendig vis gir dårligere IPC gitt samme bredde. om en øker bredden (eg. antall pipelines) så kan selvsagt IPC øke.

 

Ellers anbefaler jeg å lese litt om pipelines! Cache er ikke det som gjør at en lengre pipeline ikke medfører lavere IPC. Den har faktisk svært liten effekt på ytelse ved forskjellig pipeline lengder. Cache reduserer IPC tap pga høy latency til minnet. Så godt som nix og nada med pipeline lengden å gjøre.

 

 

Skrevet: 06/02/2004 : 12:10

"NW II" hadde vel toppet ut på 4 GHz. Det som sinker Prescott er dobbel delay på L1 og L2 cache. Lengre pipelinen er bare marginalt bremsende på ytelsen. Det snakkes om 0.75 misspredicts per 100 instruksjoner.

http://www.xbitlabs.com/articles/cpu/display/prescott_5.html

 

Siden pipeline er 55% lengre kan vi gjøre litt blunt matte, som vil gi et overslag på hvor mye selve pipeline forlengelsen utgjør i IPC tap: 55%*0.75%= 0.4% Altså 0.4% lavere IPC pga 55% lengre pipeline! (Edit: dette i forhold til "NW II") Det som hemmer Prescott er den doble forsinkelsen til L1 og L2 cache.

 

Pipeline myten lenge leve...

 

 

Skrevet: 06/02/2004 : 13:07

pipeline myten enda lengre leve... nå med ny og 55% lengre smak.

 

Skrevet: 06/02/2004 : 14:21

Edit: Intel lager altså en CPU som har en rekke forbedringer og to elementer som bidrar til lavere IPC. (så langt vi vet) Hvor vanskelig er det å se at dette i hovedsak skyldes DOBBEL delay til cache? Jeg står fortsatt ved beregningene for pipeline bidraget.

 

Dette har jeg skrevet, og jeg kunne sikkert funnet en rekke andre poster der jeg gjentar meg selv. Det aller meste er svar til deg så dette burde du fått med deg.

 

Skrevet: 22/01/2004 : 13:08

Jeg har tydeligvis ikke vært klar nok i posten min.

 

Prescott med 22 steg pipeline vil få en høyere "straff" for misprediction enn NW. Det sier seg selv.

 

Jeg poengterer (som jeg har gjort i 6 mnd nå) at Prescott er langt mer enn kun 2 nye stegs pipeline og at de andre forberingene veier opp. Videre at jeg tror Prescott jenvt over vil bli 5-10% raskere pr MHz. Trolig mer 5% enn 10%.

 

Lavere IPC får en kun når det er snakk om oppgaver som har høy grad av branching ref det jeg skrev over. På multimedia o.l. vil prescott styrke P4 NW sin gode posisjon. I det hele tatt kan en vel si at Prescott vil bli bedre der NW er god og muligens dårligere til en del av oppgavene NW er dårlig på.

 

Skrevet: 22/01/2004 : 18:32

Med Knikk Knakk sin logikk så skjønner jeg ikke hvor Intel ikke bare løser problemet og legger inn en pipeline på et par hundre stages. Da må jo ytelsen bli fenomenal ettersom det vil "hjelpe både single thread og HT modus.

 

Hint: "out-of-order superscalar execution engine""

 

Skrevet: 22/01/2004 : 21:57

10% lengre pipelines vil føre til lavere IPC _ISOLERT SETT_ (grunnet høyere "branchstraff"). Det kan veies opp av andre endringer, og som jeg har sagt N-antall ganger tipper jeg at Prescott vil få 5-10% høyere ytelse pr MHz opp mot NW (fortsatt mer 5% enn 10%).

 

Det du derimot påstår er at lengre pipeline hjelper til på ytelsen uten å kunne begrunne det på noen som helst måte.

 

Skrevet: 27/01/2004 : 21:55

Dersom testen deres er representativ så tok jeg nok feil mht ytelse på Prescott og mine antatte 5-10% (mer 5% enn 10%) bedre ytelse enn NW. Det ser jo ut som om Prescott blir en del tregere pr MHz enn NW.. Det synes jeg vil være rart. Vel å merke kan de ha lagt inn mye lengre pipelines som gjør at ytelsen går ned, men den diskusjonen kan vi ta når vår test kommer ut. OK?

 

 

Skrevet: 02/02/2004 : 10:52

Grunnen til at Prescott ikke yter langt bedre enn Northwood er jo nettopp den ekstremt lange pipelinen som senker IPC. Å påstå noe annet blir bare meningsløst. Alle skjønner jo at en P4 Northwood med 1 MB L2 cahche vil yte bedre enn en med 512 KB L2. At Prescott da yter dårligere til tross for mange andre forbedringer viser hvor mye den lange pipelinen har å si for ytelsen.

 

Dette viser at du har tatt feil hele tiden med dine påstander som at desto lengre pipeline desto bedre IPC.

 

 

Skrevet: 02/02/2004 : 11:59

Videre påpeker jeg at Prescott, i følge de som har testet den, har DÅRLIGERE ytelse pr MHz enn NW. Det er kun en ting med Prescott som alle (andre enn deg da...) er enige om at gir lavere IPC og det er de ekstremt lange pipelinene.

 

 

Skrevet: 06/02/2004 : 14:50

Knikk Knakk: Ringer det ikke en liten bjelle når Prescott blir raskere i oppgaver den det er lite eller ikke noe branching og opp til 16% tregere i oppgaver med mye branching?

 

Det burde vel tilsi at når Prescott får branch missprediction så har det langt mer å si enn for Northwood? Eller mener du at det kun kommer av høyere delay mot cachen (som er dobbelt så stor)?

 

Det du sier er at Intel la inn dobbelt så mye L2 cache og at det førte til lavere IPC... Synes det blir litt rart at Intel skulle gjøre noe slikt...

[Knick Knack]

Interessant å levere en rekke quotes tatt fullstendig ut av sammenhengen. I tillegg har du quotet meg på ting jeg korrigerte umiddelbart. Dette høres ut som dårlig valgflesk. Er dette en kampanje for deg? prøv heller å kom med et fornuftig bidrag ref. min forrige post.

[The Jackal]

Interessant å levere en rekke quotes tatt fullstendig ut av sammenhengen. I tillegg har du quotet meg på ting jeg korrigerte umiddelbart. Dette høres ut som dårlig valgflesk. Er dette en kampanje for deg? prøv heller å kom med et fornuftig bidrag ref. min forrige post.

Det går vel kanskje an å være litt ydmyk å kunne innrømme at du faktisk har feil. Skal vel godt gjøres å trekke så mange quotes ut av sammenhengen. Betviler ikke dine kunnskaper Knick Knack, men selv de beste har feil innimellom.

[Jarmo]

Knick Knack: Hva er meningen med selvmotsigende og kverulenrende

poster når man vil videre med kunnskaper i slike tråder som denne ?

 

Jeg følger med disse postene og blir av og til distrahert og usikker

av info som ikke har logiske tankeganger bak seg....

 

Nå er jeg jo bare en læregutt i forhold til dere "store gutter" men

kanskje en dag vil jeg bli litt større jeg også

 

Hadde vært mer triveligare å lese disse postene hvor velfundert kunnskap

og lærerik informasjon er viktigare enn personlig kamp om meninger

og hvor man tar lite hensyn til andre forumdeltagere/lesere.

 

Jeg har selvfølgelig dannet meg et bilde av denne og andre tilsvarende

tråder hvor du har vært aktiv deltager og etter min mening

har din kommunikasjonsmåte vært ødeleggende i flere tilfeller

for trådene, dessverre.

 

Men det er aldri for sent å snu ang. kommunikasjon, det heter

personutvikling i høyeste grad, det

 

Håper at du ikke ta dette personlig og at du kan konstatere at jeg er

ute etter en bedre kvalitet over diskusjoner som blir levert her.

 

 

No bad feelings og fortsatt en god dag til deg og alle andre!

 

Mvh

jarmo

[snorreh]

http://stanford-online.stanford.edu/course...7-ee380-100.asx

 

Interessant

Den der er med AMD fyren, i innlegget du siterte som jeg nå har redigert finner man ex intel arkitekten.

Ja, jeg ser det nå. Beklager rotet, rett link er:

http://stanford-online.stanford.edu/course...8-ee380-100.asx

 

Endret 23. februar 2004 av snorreh

[b0nna]

"In its biggest strategic mistake in a decade, Intel has spent an estimated $2 billion creating a high-speed computer chip, the Itanium, that most customers don't want and don't need."

 

http://www.bradenton.com/mld/bradenton/bus...ogy/8064696.htm

[snorreh]

Skulle ikke forundre meg om AMD følger etter Intel om en 5-10 års tid og implementerer EPIC de også.

AMD var faktisk inne på en lignende tanke lenge før IA-64/EPIC i det hele tatt var påtenkt med sin 29K prosessor, men valgte å droppe videreutviklingen av denne til fordel for å produsere Intel-kloner:

http://www3.sk.sympatico.ca/jbayko/cpu4.html#Sec4Part3

 

"Advanced Micro Devices retargeted it as an embedded processor (introducing the 292xx series), and in late 1995 dropped development of the 29K in favour of its more profitable clones of Intel 80x86 processors, although much of the development of the superscalar core for a new AMD 29000 (including FPU designs from the 29050) was shared with the 'K5' (1995) Pentium compatible processor (the 'K5' translates 80x86 instructions to RISC-like instructions, and dispatches up to five at once to the functional units.

 

Most of the 29K principles did live on in the Intel/HP IA-64 architecture:"

http://www3.sk.sympatico.ca/jbayko/cpu6.html#IA-64

 

"Integer registers are arranged as a stack as in the AMD 29K (GR0-GR31 correspond to 29K's global registers, GR32-GR127 to the stack), requiring a separate register cache stack and a regular execution stack (note of irony: AMD abandoned the 29K to concentrate on it's 80x86 clones, while Intel is replacing the 80x86 with an architecture similar to the 29K). While the 29K uses a stack pointer register (registers are selected releative to the stack base pointer), IA-64 renames registers implicitly (GR32 is still referred to as GR32, though it may map to any of the 96 stack registers), and registers are spilled and filled automatically in the IA-64 (during call or return instructions - the "register frame" is specified by an alloc instruction)."

 

Rart å tenke på i dag

[Knick Knack]

Så forresten det foredraget til AMD's Kevin McGrath for andre gang her om dagen. La merke til at K8 kjernen faktisk har mange likheter med IA-64. Som han selv sa det; prosessoren var egentlig en VLIW prosessor. Den samlet opp 3 og 3 instruksjoner parallellt og hadde 11 issueports. blokk skjemaet for cpu backend minner faktisk mye om Itanium. Selvsagt er der masse x86 arv som tynger den slik at den teoretisk ikke kan kjøre mer enn halvparten så høy IPC som Itanium og den har 8-9 pipelinesteg som er totalt unødvendige i Itanium... gjett hvem som kommer til å dra nytte av det

Endret 4. mars 2004 av Knick Knack