Xeon, Itanium med integrert minnekontroller

[Anders Jensen]

Del: At standarder får monopol er ikke akkurat så bra det heller. Det hindrer utviklingen. Med SCI er vel tanken til Intel at Itanium platformen skal bli mye billigere å produsere. Hovedkort og servere vil jo kunne lages over en lest for dem begge og det vil nok gi IA64 langt lettere akseptans i markedet. Det er bra siden x86 ved å dra med seg apple i den enorme teknologihengemyra kalt x86 medfører ytterligere innsnevring i valgmulighetene.

 

Folk som forstår seg på Tomasulos algoritme og betydningen av wire delay i CPU design har rista på hue i ti år nå. Det er ikke veldig lenge til resten gjør det samme opp mot en vegg. Tipper vi vil se det allerede på ytelsesgevinsten, eller rettere sagt mangelen på sådan i neste gen x86 kjerner (Merom og k10) kontra Montecito og dens 65nm variant.

 

Det ser ut til at både Intel og AMD vil prøve å komme seg opp fra 3 issue til 4 issue prosessorer. Det vil koste en del. Kan jo bare se på Power5 som er 4 issue, høyt effektforbruk, lav SPECint. Riktignok høy throughput og høy SPECfp. Dette er nøyaktig hva vi har i vente på prosessorer som behandler serielle instruksjons strømmer. De blir henvist til throughput oppgaver. Alle høyytelse embedded prosessorer er VLIW (TI-C6x, Philips Trimedia, Starcore, ...) Ikke lenge til det samme bildet er i servermarkedet også.

[snorreh]

Uten at jeg vet hva en CSI bus vil yte,  har integrering av minnekontrolleren med manglende båndbredde å gjøre eller er det alene ett spørsmål om latency?

Begge deler, men som med alle punkt-til-punkt busser så er så lave tilgangstider som mulig alfa & omega mhp. best mulig ytelse. Det hadde ikke vært så mye ytelse å hente ved å integrere minnekontrolleren dersom ikke Intel byttet ut FSB med noe mer effektivt samtidig. Det skulle derfor ikke forundre meg om CSI-bussen har en god del ting til felles med Alpha EV6/EV7-bussen som også HyperTransport er basert på. Mer om EV7-bussen i denne interessante infovideoen fra HP:

http://h18002.www1.hp.com/alphaserver/next...nectivityip.wmv

Endret 17. juni 2005 av snorreh

[Simen1]

Del: At standarder får monopol er ikke akkurat så bra det heller. Det hindrer utviklingen.

Jeg skjønner at x86 har en drøss med ulemper hengende igjen fra flere tiår tilbake, men jeg tror Del har et poeng. Utvikling bør ikke hindres, men det bør heller ikke konkurranse. Konkurranse uten utvikling er kjipe saker, det samme er utvikling uten konkurranse. Jeg skulle gjerne sett noe ala IA64 hvis begge disse tingene var oppfyllt. For å få det til må intel åpne standarden, men det skjer vel ikke. Da står vi fortsatt ovenfor valget mellom pest eller kolera for fremtiden. (x86 eller monopol)

 

Et kompromiss er å utvikle x86 videre. Da unngår man i hvertfall monopol. En vidreutvikling av x86 blir neppe så bra som fri konkurranse på IA64, men det er i hvertfall bedre enn både å sitte med den gamle x86 og det å sitte med et monopol.

 

Med vidreutvikling av x86, mener jeg ikke bare MMX, SSEx, 3DNow, og x86-64 men også nye og større integrasjoner. F.eks fremtidige multikjerner med flere spesialkjerner i tillegg til de vanlige. (Jeg nevnte PhysX som et eksempel i en annen tråd). Grafikk-pipelines kan også være en slik vidreutvikling av ISAet. Sikkert mange andre smarte ting også. Ting som fremtidens behov vil utforme. Slike utvidelser vil kunne avlaste x86-kjernen fra de tingene den egner seg minst for. På denne måten kan vi vidreføre kompatibilitet uten at man trenger å la all koden sitte i "x86-hengemyra".

 

Så lenge det står mellom pest og kolera (x86 og monopol) så ser jeg ingen bedre alternativer enn å utvide x86 ennå mer.

[Simen1]

Betyr integrert minnekontroller at de må kaste flere kjerner som ellers kunne gjenbrukes i prosessorer med lavere kvalitetskrav?

Jeg tror ikke det. Minnekontrolleren er ikke så veldig stor i forhold til en FSB-kontroller, i hvertfall ikke i forhold til arealet på dobbelkjerner. Så når de lager en dobbelkjerne, og hvis den ene ikke funker så slåes den bare av og selges som enkel kjerne. Arealmessig koster en minnekontroller på CPUen litt mindre enn en minnekontroller på et brikkesett (grunnet ca et trinn nyere prosessteknologi). Så ulempen for yield ved å ha større areal på CPU'en veies nok omentrent opp av det arealet man sparer på brikkesettet. Det blir i hvertfall ikke noen stor forskjell for oss.

[Anonym123456789]

Betyr integrert minnekontroller at de må kaste flere kjerner som ellers kunne gjenbrukes i prosessorer med lavere kvalitetskrav? 

Jeg tror ikke det. Minnekontrolleren er ikke så veldig stor i forhold til en FSB-kontroller, i hvertfall ikke i forhold til arealet på dobbelkjerner. Så når de lager en dobbelkjerne, og hvis den ene ikke funker så slåes den bare av og selges som enkel kjerne. Arealmessig koster en minnekontroller på CPUen litt mindre enn en minnekontroller på et brikkesett (grunnet ca et trinn nyere prosessteknologi). Så ulempen for yield ved å ha større areal på CPU'en veies nok omentrent opp av det arealet man sparer på brikkesettet. Det blir i hvertfall ikke noen stor forskjell for oss.

Å, jeg mente egentlig ikke arealet av kjernen, jeg mente at Xeon og Pentium ikke lenger bruker kompatible kjerner (for det gjør de nå?) etter integreringen.

[Boralis]

fantastisk hvor kjapt AMD ble en sentral del av denne tråden...

Det er ganske naturlig ettersom det er ganske opplagt for de aller fleste at Intel med disse nye grepene igjen følger i AMD sine fotspor både mhp. integrering av minnekontroller og mhp. å bytte ut FSB med punkt-til-punkt busser.

Tja fint at Intel også kan dra nytte av noe fra amd siden det i årevis har vært motsatt

[Anders Jensen]

Da står vi fortsatt ovenfor valget mellom pest eller kolera for fremtiden. (x86 eller monopol)

Med dagens utvikling mot spesialiserte prosessorer er faren for at en ny standard skal få monopol nærmest utenkelig. Om IA64 mot alle odds skulle få monopol så ville vel det ført til frigjøring av standarden fra offentlig hold. Slettes ikke den dummeste løsningen det. Jeg har heller ingen tro på at Intel vil gjøre dette av seg selv.

 

Når det gjelder patching av x86 så har det sine klare begrensninger. du har fremdeles condition code, reg-mem, seriell instr. strøm, decoding og latterlig få reg. Uansett hva du hiver etter det skal det bli vanskelig å øke hastigheten på f.eks kompilering (jit inkludert), db og general purpose computing i sin helhet. Kan dytte inn så mange SPU'er du vil.

[Anonym123456789]

Kan man ikke putte inn perfekte SPU-er for alt, og så bytte ut hovedkjernen når den ikke lenger begrenser kompatibiliteten, fordi alt kjøres på SPU-er?

[Del]

Når det gjelder patching av x86 så har det sine klare begrensninger. du har fremdeles condition code, reg-mem, seriell instr. strøm, decoding og latterlig få reg. Uansett hva du hiver etter det skal det bli vanskelig å øke hastigheten på f.eks kompilering (jit inkludert), db og general purpose computing i sin helhet. Kan dytte inn så mange SPU'er du vil.

Finfint, dette bringer jo diskusjonen opp flere hakk, alltid morsomt å komme til detaljene. Ellers blir det fort skyggeboksing. Når det gjelder reg-mem er jeg litt forvirret, hvis du her snakker om registrert RAM er vel ikke det noen begrensning i x86?

 

Når det gjelder begrepet monopol brukt om en arkitektur/standard har du et godt poeng, men jeg synes fortsatt det er en litt merkelig kobling. Dette er kanskje dog et nødvendig onde, en felles standard er jo stort sett noe vi forbrukere setter stor pris på, selv om det ofte ikke er den beste standarden som vinner frem (Beta vs. VHS f.eks., x86 vs. litt av hvert).

 

Når det gjelder condition code, så er nok det en bremsekloss i en del tilfeller (f.eks. HPC), men er det så utenkelig at en videreutvikling av x86 kvitter seg med dette?

 

Nå har jo alle datamaskiner seriell strøm av instruksjoner på et eller annet nivå, men du sikter vel til kjernenivå her vil jeg tro. Vil du da karakterisere at en dualkjerne har seriell instruksjonsstrøm? At selv en single kjerne x86 kan utføre mer enn en instruksjon pr. klokkesyklus er jo vel kjent (ref. super skalar).

 

Antall registre er vel litt drøyt. OK, x86 kan ikke hamle opp med Power5 eller Itanium2 på registre, men opp igjennom årene er det jo lagt til haugevis av registre til x86 arkitekturen, og det er vel liten grunn til å tro at ikke den trenden vil fortsette.

 

Å øke hastigheten på kompilering er jo veldig interessant for Gentoo brukere, ellers har ikke akkurat kompilering vært gjenstand for den store parallelliseringsinnsatsen. Nå er jo kompilering i seg selv en rimelig parallelliserbar affære, så der vil vel økning av antall kjerner kunne gi en skikkelig boost. Når det gjelder SPU'er husker de gamle av oss hvordan MMX ga Doom et skikkelig løft, så selv om SPU'er ikke gir bedre ytelse over hele linja, kan de vise seg å være akkurat der du helst vil ha dem...

Endret 18. juni 2005 av Del

[snorreh]

Utvikling bør ikke hindres, men det bør heller ikke konkurranse. Konkurranse uten utvikling er kjipe saker, det samme er utvikling uten konkurranse. Jeg skulle gjerne sett noe ala IA64 hvis begge disse tingene var oppfyllt. For å få det til må intel åpne standarden, men det skjer vel ikke. Da står vi fortsatt ovenfor valget mellom pest eller kolera for fremtiden. (x86 eller monopol)

 

Et kompromiss er å utvikle x86 videre.

IA64 er ganske riktig en proprietær arkitektur, men til forskjell fra x86 så kan den ikke engang lisenseres. Faktisk er det kun Intel som kan utvikle og designe Itanium-prosessorer siden lisensrettighetene til IA64-arkitekturen er så innfløkte. Spesifikasjonen til x86-arkitekturen er fortsatt også proprietær, selv om den relativt enkelt kan lisenseres. Det beste alternativet hadde vært en arkitektur (ISA) som hadde en helt åpen spesifikasjon slik som f.eks. SPARC.

 

Uansett så er denne ISA-diskusjonen rimelig foreldet nå ettersom den ble utdebatert på midten av 90-tallet og da ble x86-arkitekturen foretrukket av industrien fremfor den svært strømlinjeformede Alpha-arkitekturen, så det blir egentlig helt feil å grave opp denne debatten igjen nå. x86 er kanskje den mest dynamiske arkitekturen som har eksistert så langt, og har gjennomgått to store opprydninger i årenes løp. Den første tok Intel seg av med IA32 som kom samtidig med 80386 i 1985, mens den siste tok AMD seg av med AMD64 som kom samtidig med Opteron i 2003, og resultatet av dette arbeidet er noe de aller fleste må si seg fornøyd med. Les mer om historien til x86 her:

http://www.sasktelwebsite.net/jbayko/cpu3.html#Sec3Part7

 

Til forskjell fra tidligere der man ofte benyttet seg av lavnivå programmering (maskinkode/assembler), så benytter man seg nå til dags hovedsaklig av høynivå programmering (strukturert som f.eks. C++/Java) der valg av ISA har fint lite å si annet enn at det må være god tilgang på kompilatorer/virtuelle maskiner og utviklingsverktøy. Det er nettopp derfor at industrien har valgt x86 selv om det kanskje ikke er så veldig vakkert, men fordi det er veldig funksjonabelt og har bredest støtte.

 

Poenget mitt er at behovet for å bytte ISA egentlig er på vikende front, for med AMD64 så har x86 blitt kraftig oppgradert og nødvendigheten av nye ISA har mer eller mindre forduftet. Med denne siste store utvidelsen av x86-arkitekturen så har faktisk AMD gjort en fantastisk jobb med å modernisere og rydde opp i mye av rotet som var igjen fra IA32.

 

Hovedutfordringene med tanke på best mulig ytelse er ikke lenger bare begrenset av ISA, men vesentlig mer av programvaren (parallelisering og optimering) samt systemarkitekturen (buss, minne og I/O) man benytter og på disse områdene er det fortsatt mye å hente.

Endret 18. juni 2005 av snorreh

[kindings]

Betyr integrert minnekontroller at de må kaste flere kjerner som ellers kunne gjenbrukes i prosessorer med lavere kvalitetskrav? 

Jeg tror ikke det. Minnekontrolleren er ikke så veldig stor i forhold til en FSB-kontroller, i hvertfall ikke i forhold til arealet på dobbelkjerner. Så når de lager en dobbelkjerne, og hvis den ene ikke funker så slåes den bare av og selges som enkel kjerne. Arealmessig koster en minnekontroller på CPUen litt mindre enn en minnekontroller på et brikkesett (grunnet ca et trinn nyere prosessteknologi). Så ulempen for yield ved å ha større areal på CPU'en veies nok omentrent opp av det arealet man sparer på brikkesettet. Det blir i hvertfall ikke noen stor forskjell for oss.

Å, jeg mente egentlig ikke arealet av kjernen, jeg mente at Xeon og Pentium ikke lenger bruker kompatible kjerner (for det gjør de nå?) etter integreringen.

De skal vel kun passe i samme sokkel i første omgang?

 

Er det forresten mulig(eller hensiktsmessig) å lage en CPU med flere kjerner som støtter både IA64 og x86? Jeg klarer ikke uten videre å se fordelen, men fordelen til Itanium har vel så langt vært at den funker utrolig bra på tunge beregninger(så lenge man bruker 64 bit software hele veien)?

[snorreh]

De skal vel kun passe i samme sokkel i første omgang?

Ja, det har vært snakk om at fremtidens Xeon MP og Itanium skal dele felles sokkel og brikkesett. Dette for å gjøre det lettere for kunder som investerer i Xeon MP-løsninger å bytte til Itanium senere hvis ønskelig. I dag deler PA-RISC og Itanium felles sokkel og brikkesett, men svært få kunder har så langt byttet ut PA-RISC med Itanium av den grunn snarere tvert imot.

 

Er det forresten mulig(eller hensiktsmessig) å lage en CPU med flere kjerner som støtter både IA64 og x86?

Det var jo nettopp det Intels "Jayhawk" skulle gjøre, men den ble som kjent kansellert sammen med "Tejas" i fjor sommer så det var nok mulig men lite hensiktsmessig. Mer om dette her:

http://www.xbitlabs.com/news/cpu/display/20040512052741.html

 

Jeg klarer ikke uten videre å se fordelen, men fordelen til Itanium har vel så langt vært at den funker utrolig bra på tunge beregninger(så lenge man bruker 64 bit software hele veien)?

Vel, Itanium har faktisk vist seg å yte svært variabelt også på tunge beregninger. Noen oppgaver løser den meget bra, mens den gjør det svært dårlig på andre så jevnt over yter faktisk ikke Itanium noe særlig bedre enn sine konkurrenter selv til en vesentlig høyere investeringskostnad totalt sett.

Endret 18. juni 2005 av snorreh

[Del]

@Anders: Det gikk akkurat opp for meg hva du mente med seriell instruksjonsstrøm. Du sikter til superskalar kontra SMT, og de ventede problemene når produksjonsprosessen går nedover. Et av hovedproblemene såvidt jeg har forstått det, er at man får store problemer med å kjøre opp klokkefrekvensen, men at SMT kan være saliggjørende (dersom man bare forer prosessoren med nok tråder, og har nok båndbredde). Nå er jo allerede hyper threading representert i P4, så jeg lurer jo litt på om x86 utelukker SMT? Jeg stusser jo også litt over at Intel ser ut til å droppe hyper threading i sine nye dual core prosessorer (m.a.o. superskalar arkitektur), de kjenner vel problematikken bedre enn de fleste, og har tilsynelatende allerede kompetansen.

 

Jeg har likevel litt problemer med å få hodet mitt rundt dette. Problemet skulle vel begynt å gjøre seg gjeldende ved 90nm, men AMD sine 90nm ser allerede ut til å klokke bedre enn 113nm chipene (tilsynelatende bruker de da lengre pipelines, mens optimale pipelines når man går nedover fra 100nm skal visstnok bli kortere). Men de er kanskje akkurat i brytningsfasen, og 65nm blir prosessen hvor vi får se problemene blomstre. Det blir spennende å se, Intel har vel allerede noen 65nm engineering chips. At klokkefrekvensen stanger i taket er det imidlertidig liten tvil om, og her er jo heller ikke Itanium2 noe vidunder.

 

Jeg er litt skeptisk til hvorvidt vi i det hele tatt vil se prosessorer basert på silisium under 65nm, vi er allerede farlig nær kvantemekanikkens domene.

 

@Snorre: At Itanium2 er parkert ytelsesmessig kan vi definitivt slå fast med de nye dualkjerne prosessorene. En Itanium2 vil tape stort sett alle tenkelige benchmarks mot en toppmodell X2 eller Opteron Dualcore. Jeg synes også det er fair å sammenligne de, ytelsen til Itanium2 er jo tross alt også i stor grad basert på parallellisering, om enn på instruksjonsnivå.

[Simen1]

Del: Mulig jeg missoppfattet A.J., men med "seriell instruksjonsstrøm" tenkte jeg på det at instruksjoner og data blir sendt parallellt gjennom pipelinene (Itanium) i stedet for i flere serielle trinn. (Instruksjon 1, data 1, data 2 følger etter hverandre som et tog). Dette gjør at det tar flere klokkesykluser fra prosessoren begynner med en instruksjon til den er ferdig behandlet. Dette gir en pipeline som bruker relativt mange trinn på å beregne noe. I sterkt grende oppgaver (condition branching) så vil dataene behandles like raskt som biler som møter rødt lys hele tiden. Programmet må stoppe opp, vente til instruksjonen er ferdig, før den kan velge vei videre og la neste bit av programmet i pipelinen fortsette. En slik stopp-kjør-stopp-kjør osv hindrer ILP (Biltrafikken) i flyte jevnt og raskt av gårde. På Itanium er dette annerledes. Da kommer instruksjonene og dataene samtidig til pipelinene og går parallellt gjennom pipelinene. Når en instruksjon er utført så kan en betinget gren ett hakk bak i pipelinen velge gren på neste klokkesyklus. Dette hindrer denne stopp-kjør-stopp-kjør på sterkt betingede grener.

 

Sterkt betingede grener er vel også det som er vanskeligst å parallellisere og få til å flyte jevnt. Alt annet kan mer eller mindre kjøres parallellt med en finkornet eller grovkornet SMT, både på Itanium og x86. Begge prosessorene vil altså øke ytelsen på en del oppgaver ved økt SMT, men bare itanium kan øke ytelsen i oppgaver med betingede grener. Mulig jeg missforsto uttrykket "seriell instruksjonsstrøm" men det er i hvertfall slike jeg tolker uttrykket.

 

Del, og Snorreh: Som A.J. sier: Itanium vil fortsette å øke i ytelse når x86 vil slite mer og mer siden mer og mer. SMT på begge plattformer vil gjøre betingede grener til en viktigere og viktigere del av flaskehalsen. Så jeg tror det er alt for tidlig å utrope noen ytelsemessig vinner.

[Del]

Nei, nei, jeg mente akkurat det jeg skrev. Problemene jeg siktet til kan dere finne godt beskrevet her:

http://www.ece.purdue.edu/~vijay/papers/2004/wd.pdf

Det var i grunnen AJ's tidligere kommentarer om wire delay som gjorde at jeg tolket det dit.

[Anders Jensen]

Finfint, dette bringer jo diskusjonen opp flere hakk, alltid morsomt å komme til detaljene. Ellers blir det fort skyggeboksing. Når det gjelder reg-mem er jeg litt forvirret, hvis du her snakker om registrert RAM er vel ikke det noen begrensning i x86?

En sentral parameter som klassifiserer et ISA er om det er register-register, register-memory eller memory-memory. Dette henspeiler på hvordan basic ALU instruksjoner er bygd opp. register-memory vil si at en ALU instruksjon kan ha register referanser og minnereferanser. Register-register vil si at den kun vil ha registerreferanser. I dette tilfellet vil kun load og store ha minnereferanser. Dette er metoden alle RISC samt IA64 benytter. Memory-memory ISA er kun blitt implementert til forsknings prosjekter så langt jeg vet. Her bruker en altså ikke registre.

 

Register-memory ISA medfører en god del ekstra knoting for hardware ingeniørene da de må bygge en CPU som leter etter de kritiske minnereferansene i alt som kryper og går av ALU instruksjoner, fremfor bare å lete etter load og store instruksjonene. Det sier seg selv at det siste kan implementeres langt kjappere og med mindre effektforbruk. ARM er godt eksempel. På IA64 har en ytterligere hjelp i templatene, men jeg vet ikke om dagens itanium prosessorer er smarte nok til å benytte denne. Det er typisk prefetch som er interessert i disse minnereferansene så fort som mulig.

Når det gjelder condition code, så er nok det en bremsekloss i en del tilfeller (f.eks. HPC), men er det så utenkelig at en videreutvikling av x86 kvitter seg med dette?

Det har du nok rett i. Det hadde jeg faktisk ikke tenkt på. Kan likevel ikke helt se for meg dette gjort i praksis. Da snakker vi om en rimelig heftig omstrukturering av instruksjonssettet. Det vil neppe bli kompatibelt på noe vis, men kan kanskje komme som en ekstra modus. Det vil jo uansett bli litt av ei suppe å støtte to forskjellige kontrollflyt mekanismer. Dette er tross alt den komplekse delen, hvor alt annet blekner i forhold... To typer branch evaluering er galt nok, problemet blir når du skal støtte to typer branch prediction og prefetch. Blir vel litt som å krysse bil og båt. Det er jo mulig, men hvor ofte er det smart?

Nå har jo alle datamaskiner seriell strøm av instruksjoner på et eller annet nivå, men du sikter vel til kjernenivå her vil jeg tro. Vil du da karakterisere at en dualkjerne har seriell instruksjonsstrøm? At selv en single kjerne x86 kan utføre mer enn en instruksjon pr. klokkesyklus er jo vel kjent (ref. super skalar).

VLIW og EPIC har en parallell strøm sett på logisk nivå fra prosessoren. Dvs. prosessoren tar imot instruksjonene på et format som forteller den eksplisitt at de er parallelle. For VLIW er disse formatene meislet i stein med fast bredde og fast instruksjonstype i hver slot. For EPIC er en kun begrenset av utvalget av templates og måten de kan kombineres på. I praksis betyr det at du kan sende alt fra 1 instruksjon og oppover i parallell. Tror faktisk ikke de han lagt inn noen begrensning fordi det er mer komplisert å legge den inn enn å la være i dette tilfellet. Den praktiske begrensningen ligger som oftest i hvilken instruksjonsmiks og hvor mange instruksjoner en IA64 CPU kan ta rotta på i slengen. Per i dag kan den ta unna 11 instruksjoner på en klokkesyklus, men den kan bare decode 6 instruksjoner (2 bundels) per klokkesyklus. Årsaken til missmatchen kan illustreres ved følgende corner case: La oss anta at kompilator har funnet en instruksjon som må kjøres alene, etterfulgt av 11 eller flere parallelle instruksjoner. Kompilatoren vil da dele dette opp i to grupper (som ikke er det samme som en bundel) delt av spesielle skillere som er predefinert i en av de 28 templatene som er tilgjengelig (4 templates er ikke definert, en template er 5bit og fungerer som en header i en bundel som er 128bit). Prosessoren vil dekode de to første bundlene som altså definerer første gruppe kun bestående av en instruksjon samt de fem første instruksjonene i neste gruppe. Instruksjonene havner så i et buffer som kan romme 12 instruksjoner (4 bundels). På neste klokkesyklus vil første gruppe (den enslige instruksjonen) påbegynne utførelsen, mens de fem andre må bli liggende i bufferet. De neste 6 instruksjonene blir også decodet på denne syklusen og havner i bufferet sammen med de fem som er der allerede. på neste syklus igjen vil CPU kunne sette i gang utførelsen av 11 instruksjoner gitt at kompilatoren fant en instruksjons miks som matcher kjernens tilgjengelige ressurser. Tilgjengelige ressurser bør i dette tilfellet defineres litt bredere enn kun antall execution units. En må også ta hensyn til registerfil ports tilgjengelighet av tidligere prosesserte resultater (pipeline forwarding) osv.

 

Poenget er ikke å få høyest mulig peak IPC, men høyest mulig sustained IPC. Det at Itanium 2 har 11 issue ports mot Power5 sine 4 og Opteron/xeon sine 3 sier jo litt om hvor mye mindre kompleksitet som ligger bak en bred IA64 kjerne. Itanium 2 støtter også FMAC så du vil se noen steder at det påberopes 8 instruksjoner sustained per syklus. Dette fordi det er vanlig å regne FMAC som to instruksjoner.

 

Med overgangen til Montecito er det gjort en del grep som skal gjøre det lettere for kompilator å utføre flere instruksjoner per klokkesklus. Blandt annet har registerfila fått to nye ports, opp fra 20. Det vil også bli hardware støtte for multithreading slik at f.eks speculative precomputation (også kjent som helper threading) kan gjøres langt mer effektivt. I dag kjøres dette på Virtual Multithreading i Itanium 2 med 5% eller mer ytelsesgevinst. Største gevinsten vil nok likevel komme via TLP throughput.

Antall registre er vel litt drøyt. OK, x86 kan ikke hamle opp med Power5 eller Itanium2 på registre, men opp igjennom årene er det jo lagt til haugevis av registre til x86 arkitekturen, og det er vel liten grunn til å tro at ikke den trenden vil fortsette.

x86-64 har 16 GPRs Power har 32 Alpha har vel 41 og IA64 har 128. Det vil medføre en nokså drastisk omlegging av x86-64 å legge til flere registre fordi de mangler ledige adresse bits for adressering av registrene.

 

Å øke hastigheten på kompilering er jo veldig interessant for Gentoo brukere, ellers har ikke akkurat kompilering vært gjenstand for den store parallelliseringsinnsatsen. Nå er jo kompilering i seg selv en rimelig parallelliserbar affære, så der vil vel økning av antall kjerner kunne gi en skikkelig boost. Når det gjelder SPU'er husker de gamle av oss hvordan MMX ga Doom et skikkelig løft, så selv om SPU'er ikke gir bedre ytelse over hele linja, kan de vise seg å være akkurat der du helst vil ha dem...

En kompilerings jobb er nærmest "embarrassingly parallel" men komponentene er på sin side nesten umulig å parallellisere. Altså vil Mr. Amdahl slå hardt og brutalt ned her med en gang du begynner å legge til flere kjerner enn du har antall parallelle jobber.

 

Wire delay problematikken jeg tok opp har ikke mye med SMT å gjøre. Jeg sikter til wire delay ved bruk av reservation stations (Tomasulos algoritme). Det er enorme mengder data som skal sendes bakover og rutes riktig vei i en OoO pipeline for å fortelle reservation stationene at deres respektive instruksjon nå har alle ressurser reservert og kan påbegynne execution. Denne tilbakekoblingen gjør designet ekstremt komplisert. Mesteparten av effekten en moderne OoO CPU svir av skjer i denne delen. Problemet med slik tilbakekobling for å oppdrive ILP er at du får en del intern ping - pong delay samt et massivt virvar av legninger i hytt og pine. På in-order prosessorer har du ingenting av dette og det er grunnen til at de kan yte langt bedre per watt. Det er også grunnen til at in-order kjerner vil bli brukt i PS3, Xbox360 og Nintendo ved neste generasjonsskifte. Disse baserer seg imidlertid på TLP fremfor ILP for å oppnå høy IPC siden de opererer på PPC ISAet som presenterer CPU med en seriell instruksjonsstrøm og dermed ville krevd OoO for å finne tilbake all ILP kompilatoren tidligere har funnet men ikke har mulighet til å fortelle CPU om. Det er faktisk et litt morsomt paradoks at moderne kompilatorer modellerer OoO prosessorer som en VLIW for å se for seg hvordan den skal plassere instruksjonene best mulig.

Endret 19. juni 2005 av Anders Jensen

[MadRos]

Jeg syns at det er irriterende at AMD som "finner opp" nye ting så kommer den store og slemme intel "stjeler" deres ideer...

[Anders Jensen]

Jeg syns at det er irriterende at AMD som "finner opp" nye ting så kommer den store og slemme intel "stjeler" deres ideer...

Bortset fra at jeg har til gode å se et eneste nytt konsept fra AMD som ikke har vært implementert i andre maskiner før... Tror du skal lete veldig nøye blandt Intel sine produkter for å finne noen helt nye konsepter også. Det meste "nye" har vært implementert i en eller annen IBM mainframe for 30 år siden. Det er altså ikke snakk om å finne opp hverken krutt eller hjul her, men å velge blandt teknologier. Det er nok ikke ofte at ytelse er det tyngst veiende argumentet for implementering av en teknologi. Det er nok oftere foretningsmessige årsaker. Slik som å ta vare på arv. Det viser seg ofte i form av valg av ISA og kommunikasjonsgrensesnitt.

Endret 19. juni 2005 av Anders Jensen

[snorreh]

Del, og Snorreh: Som A.J. sier: Itanium vil fortsette å øke i ytelse når x86 vil slite mer og mer siden mer og mer. SMT på begge plattformer vil gjøre betingede grener til en viktigere og viktigere del av flaskehalsen. Så jeg tror det er alt for tidlig å utrope noen ytelsemessig vinner.

Tja, hvis du tenker på Itaniums predikering (ILP) så ser det kanskje pent ut på papiret (i teorien), men fungerer dessverre svært dårlig i praksis ettersom det i dag kun medfører tap av ytelse (bortsett fra i SPEC-tester selvsagt). Dette skyldes at ikke alle eksekveringsenhetene på Itanium blir fullt utnyttet hele tiden selv med bruk av blodtrimmede kompilatorer, så det er kanskje på tide at noen ser realitetene i øynene snart synes jeg. Likevel så er dette langt ifra noen dum idé, så det er synd at det ikke fungerer like bra i praksis som det var planlagt.

 

Predikering er forøvrig ikke unikt for Itanium, x86-prosessorer har også hatt en form for dette siden Pentium Pro. Forbedring av "on die branch (mis-)prediction" på x86-prosessorer har så langt vist seg å gi større ytelsesøkninger enn kompilatorer på Itanium så jeg ser ingen grunn til at det ikke skal fortsette. Det er også veldig få algortimer som lar seg automatisk parallellisere, så da koker det ned til hvor raskt en prosessor klarer å kjøre enkle tråder og da er "on die" som regel mest effektivt.

 

Selv har jeg størst tro på flere eksekveringsenheter (ALU/FPU/SIMD) på x86-prosessorer siden det automatisk gir parallelisering, dernest ser jeg frem til enda flere kjerner i prosessorene. AMD har som kjent satset mye på å ha mange eksekveringsenheter på sine prosessorer, og de skal også satse tungt på flerkjerne-prosessorer fremover. Dobbelkjerne Opteron har allerede vist seg å være veldig effektiv på dette siden eksekveringsenhetene der slipper å dele cache som er helt avgjørende med tanke på best mulig ytelse. Tar man også totalprisen med i beregningen så er det liten tvil om hva som representerer den beste løsningen etter min mening.

Endret 19. juni 2005 av snorreh

[Anders Jensen]

Selv har jeg størst tro på flere eksekveringsenheter (ALU/FPU/SIMD) på x86-prosessorer siden det automatisk gir parallelisering,

Oi, loop. Den har vi sett før. Merkelig at noen fortsatt tror på dette.