Intel vil vise ny prosessorarkitektur

[int20h]

I løpet av et par uker kommer Intel til å demonstrere en ny prosessorarkitektur der stikkordene er multikjerne, energieffektivitet og høy ytelse. Teppet går opp under Intel Developer Forum den 23. august.

Les mer

[CAT0]

Lurer på hvor lenge vi blir sittende med den allerede aldrene x86 teknologien ....

[ATWindsor]

Lurer på hvor lenge vi blir sittende med den allerede aldrene x86 teknologien ....

Er x86-tekonolgien så ille egentlig? eg har hørt at moderne CPUer uansett "kjører sitt eget løp" arkitekturmessig, og slenger på et par transistor på toppen for å være x86-kompatible, noen som kan komme med noe mer innsikt om dette?

 

AtW

[efikkan]

Det er på tide at Intel bytter ut netburst.

 

Lurer på hvor lenge vi blir sittende med den allerede aldrene x86 teknologien ....

x86-teknologien ble kraftig forbedret av AMD ved AMD64.

[Dragavon]

stikkordene er multikjerne, energieffektivitet og høy ytelse.

 

Sånne prosessorer lanserte jo AMD for to år siden

[el_salvad]

Får virkelig håpe Intel klarer å komme opp med noe skikkelig bra i fremtiden.

[Simen1]

Dragavon: AMD har ennå ikke lansert noen multikjerne CPU (mer enn 2 kjerner på en brikke)

 

Jeg mener at x86 er ikke utdatert. Det er bare ganske gammelt og har en del ineffektivtieter som både sluker ytelse (i en del situasjoner) og som sluker et høyt antall transistorer "på toppen" for å få den nevnte bakoverkompatibiliteten. Jeg har hørt at "oversetteren" mellom x86 og CPU'ens indre kode tar en ganske stor del av kjernen på en CPU. Tror jeg har hørt 30 eller 40% av selve kjernen (uten L2 cache). Jeg er ganske usikker på om det stemmer så jeg håper noen med peiling kan utdype dette mer.

 

Den nye arkitekturen virker veldig spennnende. Jeg tror AMD vil møte vesentlig hardere konkurranse på ytelse og ytelse/watt fra Intel når denne kommer. Med såpass mye forskningsmidler skal det mye til at de ikke klarer å komme opp med en slagkraftig CPU.

Endret 15. august 2005 av Simen1

[ATWindsor]

. Jeg har hørt at "oversetteren" mellom x86 og CPU'ens indre kode tar en ganske stor del av kjernen på en CPU. Tror jeg har hørt 30 eller 40% av selve kjernen (uten L2 cache). Jeg er ganske usikker på om det stemmer så jeg håper noen med peiling kan utdype dette mer.

Jepp, det bifalles, har nemlig hørt at det bare er et par prosent på en morderne CPU, så det hadde vært interessant å få dette på det rene.

 

AtW

[kindings]

Lurer på hvor lenge vi blir sittende med den allerede aldrene x86 teknologien ....

x86-teknologien ble kraftig forbedret av AMD ved AMD64.

å slenge på instruksjoner for 64 bit er neppe noe "kraftig" forbedring av arkitekturen... heller en naturlig evolusjon etter min mening. Hadde ikke AMD gjort det, så hadde sikkert Intel gjort det, uenigheten var visstnok tidpunktet det skulle gjøres på. Intel mente det var bortkastet da AMD gjorde det, mens AMD mente at det var på sin plass(åpenbart). Dog heller jeg vel heller litt mot Intel her, de fleste som kjøpte de første 64 bits CPUene til AMD fikk neppe brukt disse instruksjonene(ble mye en hype?) fordi man ikke hadde gjort god nok oppfølgning på software/OS siden(det kan man egentlig skylde på hvem som helst)...

 

edit: Athlon 64 kom vel strengt tatt med flere forbedringer som var langt mer viktige enn 64 bits instruksjoner.

Endret 15. august 2005 av kindings

[Anders Jensen]

Hovedproblemet med oversetterkretsene er ikke transistor antallet, men at de legger til forsinkelse i "critical path" og brenner av energi som ikke brukes til nyttig arbeid. Oversetterne er likevel ikke den største hemskoen til dagens prosessorer. Det største problemet er tilbakekoblings nettverket som oppdaterer tilstanden til såkalte reservation stations.

 

Litt mer om oversetterkretsene:

 

På P4 (alle versjoner) ligger oversetteren mellom L1 og L2 cache (derfor har de endret navn på L1I cache til trace cache) og den vil derfor legge til forsinkelse på L1I (trace cache) miss. Dette merkes best på L2 hit siden oversetteren bidrar en vesentlig del av forsinkelsen. For main memory hit blir den ekstra forsinkelsen neglisjerbar. For alle andre aktuelle prosessorer ligger oversetteren mellom L1 cache og resten av kjernen. Det medfører at alle instruksjoner må oversettes for hver gang de skal utføres og en får ekstra "load to use" forsinkelse fra alle nivåer i minnehierarkiet. Den ekstra forsinkelsen i "load to use" for L1I er imidlertid hovedproblemet.

 

Den neste generasjonen Intel prosessorer tar antagelig utgangspunkt i P6 lignende design (dvs tilsvarende optimaliseringsregler gjelder, selve kjernene ligner ikke lengre på P6 mer enn et boretslag i Lillestrøm ligner på Oslo) og tilfører en del teknikker vi kjenner fra P4. Tracecache er nok av de mest aktuelle. Hyperthreading kommer nok også, men det er egentilig ikke en "P4 teknikk" i mine øyne og den må nødvendigvis redesignes kraftig for andre kjerner enn P4 da teknikken består i å gjøre de eksisterende ressursene i prosessoren klar over at de må skille mellom hvilken tråd gjeldende operasjon skal gjelde for.

 

Håper vi også får litt mer info om Montvale, Tukwila og Poulson på IDF. Det er jo tross alt her det mest interessante ligger... for meg i allefall . Montvale skal i følge HP komme ut i området 2.5GHz - 3GHz (Montecito i området 2.0-2.5). Det har vært litt motstridende meldinger om hva slags prosessteknikk Montvale kommer på. De siste meldingene tyder på at det er snakk om en 90nm remake av Montecito. Med andre ord er IPF i ferd med å ta igjen PM og k8 på frekvens i 90nm noden.

 

Det er også på tide at Intel avslører hvordan CSI skal implementeres. Det er uten tvil det mest interessante prosjektet hos Intel for tiden. CSI er et felles grensesnitt for tilkobling av Xeon og IPF prosessorer i servere. Miksing av de to prosessorene i samme maskin _kan_ bli aktuelt, men er ingen selvfølge. I dag mikser HP PA-RISC og IPF i samme maskin, men ikke i samme hardware partisjon. Med SX2000 chipsettet (ikke lansert ennå) vil det bli mulig å mikse PA-8900 med Montecito og Montvale.

 

CSI er forventet å bli basert på en seriell link ikke ulik PCIe og Infiniband. Topologien for forskjelling N-way maskiner er det ingen gode rykter på.

Endret 15. august 2005 av Anders Jensen

[el-asso]

Athlon 64 kom vel strengt tatt med flere forbedringer som var langt mer viktige enn 64 bits instruksjoner

 

Jepp, dobling av antall GPRs fra 8 til 16 som (i tillegg til at disse kan kjøre i 64 bits "long" mode) og dobling av 128 bits SSE/SSE2 registere fra 8 til 16.

 

Litt om kode og registere i:

http://www.cpuid.org/reviews/K8/index.php

Indeed, 64 bits instructions use 64 bits operands (memory address, immediate values), that's twice the size of 32 bits code. Moreover, in the case of AMD64, 64 bits instructions use the REX prefix, that adds one more byte to the instruction size. Finally, SSE/SSE2 instructions also use a prefix.

 

[.......]

 

We can estimate that a 64 bits code will be 20-25% bigger compared to the same IA32 instructions based code. However, the use of sixteen GPR will tend to reduce the number of instructions, that could cause the 64 bits code to be shorter than the 32 bits code. This will depend on the function complexity, and of course on the compiler.

 

Besides, the K8 is able to handle the code size increase, thanks to its 3 decoding units, and its big L1 code cache. The use of big 32KB blocs in the L1 organization in order seems now very useful !

 

 

Tilbake til Intel:

 

På P4 (alle versjoner) ligger oversetteren mellom L1 og L2 cache (derfor har de endret navn på L1I cache til trace cache) og den vil derfor legge til forsinkelse på L1I (trace cache) miss.

Må faktisk ta 8 ekstra trinn i pipelinen ved miss.

 

Den neste generasjonen Intel prosessorer tar antagelig utgangspunkt i P6 lignende design (dvs tilsvarende optimaliseringsregler gjelder, selve kjernene ligner ikke lengre på P6 mer enn et boretslag i Lillestrøm ligner på Oslo) og tilfører en del teknikker vi kjenner fra P4. Tracecache er nok av de mest aktuelle. Hyperthreading kommer nok også, men det er egentilig ikke en "P4 teknikk" i mine øyne og den må nødvendigvis redesignes kraftig for andre kjerner enn P4 da teknikken består i å gjøre de eksisterende ressursene i prosessoren klar over at de må skille mellom hvilken tråd gjeldende operasjon skal gjelde for.

Behovet for HT syntes noe diffust i disse dobbeltkjernetider?

 

Jeg mener også å ha lest at PM har en bedre BPU en P4. Mulig det kommer en arkitekturmessig klone på den fronten også?

 

 

Edit: Glemte en quote

Endret 15. august 2005 av el-asso

[Simen1]

Lurer på hvor lenge vi blir sittende med den allerede aldrene x86 teknologien ....

x86-teknologien ble kraftig forbedret av AMD ved AMD64.

å slenge på instruksjoner for 64 bit er neppe noe "kraftig" forbedring av arkitekturen...

Enig. Det er en evolusjon snarere enn en revulosjon. Selve prinsippet med å utvide instruksjonssettet til x86 for å fjerne diverse flaskehalser tror jeg ikke vi har sett slutten på. Tidligere utvidelser har innebært hovedsaklig x87 (FPU), MMX, SSE, SSE2, SSE3, 3DNow!, 3DNow! Enhanced, AMD64 og NX-bit. For ikke å snakke om da det dukket opp egne grafikkbrikker som tok seg av bestemte instruksjoner for å avlaste de vanlige CPU'ene. Slike utvidelser tror jeg vi kommer til å se flere av i tiden fremover. Nærliggende ting er blandt annet noen instruksjoner til viritualisering, og utvidelser av AMD64 (noe AMD har på veikartet sitt). Intel kommer neppe til å ligge på latsiden heller når det gjelder instruksjonssett (de har blandt annet innført både SSE3, NX-bit og iAMD64 i det siste). Nye koprosessorer kan sikkert også bli akutellt de neste årene (Phys-X og lignende). Siden x86 kan utvides på denne måten så mener jeg at det ikke er så viktig om ytelsen til den gamle, sentrale x86-kjernen henger en del etter. Det viktigste er bakoverkompatibilitet, så kan total ytelse følge en evulosjonær bane med utvidelser. Selv om hverken nåværende eller fremtidige kjerner blir særlig teknisk elegante så tror jeg de fortsatt har et langt liv forran seg.

 

Anders Jensen: Takk for utdyping av det med oversetteren.

[Anders Jensen]

Behovet for HT syntes noe diffust i disse dobbeltkjernetider?

Ja det kan virke slik. Svaret er som alltid: det kommer an på...

 

Power5 er jo et godt eksempel på at SMT har mye for seg selv med dobbelkjerne og SMP opp i mente. Det er et økende problem at minneytelsen henger etter CPU ytelsen og da må en ta i bruk alle triks for å kompensere for dette. Med økt bruk av flertråding fra programmerere vil SMT bli mer nyttig, også i flerprosessorsystemer.

 

Jeg er imidlertid enig i at SMT nok kan vise seg å bli en unyttig teknologi i miljøer hvor ytelse per tråd er viktigst. SMT vil medføre noe lavere ytelse per tråd enn hva en kunne oppnåd ved å fjerne det. En ting er at en kan oppnå bedre ytelse per tråd vel å disable SMT på en chip som har det, men en kunne også tjent en del ved å ikke ha det med i designet i det hele tatt i form av høyere frekvenser og/eller lavere effektforbruk. Tidsperspektivet er imidlertid ikke trivielt å si noe fornuftig om. Så lenge vi ser samme kjerne brukt i servere og desktop fra Intel så vil nok SMT være implementert om ikke slått på. Jeg tror imidlertid at Intel vil bruke tilsvarende kjerner på laptop og desktop i fremtiden og la servere kjøre sitt eget løp med egne kjerner også for x86. Det ser ut til å være en mer naturlig oppdeling enn å ha laptop for seg selv og server og desktop på samme kjerne slik det er nå. Jeg tror også vi vil se IPF maskiner komme krypende nedover i mellomklasse størrelse for servere og kanskje for små servere også. Det gjør det mindre viktig for Intel å ha en egen x86 server kjerne. De kan heller bruke en vanlig desktop/laptop kjerne med CSI grensesnitt for de segmentene de ikke leverer IPF til.

[mar]

Behovet for HT syntes noe diffust i disse dobbeltkjernetider?

 

Dette kan virke litt meningsløst ja. Får håpe at det er med av hensyn til ytelsen og ikke av markedsføringshensyn.

 

Blir vell en vesentlig kortere pipline i disse nye prosessorene, noe som reduserer behovet og gevinsten av HT. En mulighet er vell at bredden økes slik at det i en del tilfeller blir problemer med å fordele en enkelt tråd slik at den bruker alle tilgjengelige resurser, noe som igjen vill føre til at HT kan være med på å øke ytelsen.

 

Mulig jeg er helt på villspor her, men er det noen som ser andre gode grunner til å inkludere HT?

 

Edit: Som nevt over er kamuflering av minneforsinkelser en mulig grunn. Kan ikke dette slå litt ut begge veier? Tenker da på tilfeller der to tråder som kjører samtidig ødelegger for hver andre (siden de deler en begrenset mengde cache). Med bare en kjerne er det greit. Siden det i svært mange tilfeller fører til et system som oppleves litt kvikkere, men med 2 kjerner blir neppe forskjellen like stor.

Endret 15. august 2005 av mar

[Boralis]

Blir iallefall spennende å se hvor dette fører hen, får iallefall håpe ta det blir prosessore som bruker mindre strøm og dermed produserer mindre varme. Samtidig er det å håpe at disse blir hakket raskere enn A64, da det vil føre til et "nytt" kapløp og lave priser.

[Anders Jensen]

Behovet for HT syntes noe diffust i disse dobbeltkjernetider?

 

Dette kan virke litt meningsløst ja. Får håpe at det er med av hensyn til ytelsen og ikke av markedsføringshensyn.

 

Blir vell en vesentlig kortere pipline i disse nye prosessorene, noe som reduserer behovet og gevinsten av HT. En mulighet er vell at bredden økes slik at det i en del tilfeller blir problemer med å fordele en enkelt tråd slik at den bruker alle tilgjengelige resurser, noe som igjen vill føre til at HT kan være med på å øke ytelsen.

 

Mulig jeg er helt på villspor her, men er det noen som ser andre gode grunner til å inkludere HT?

Hovedgrunnen til å ta med HT (SMT) er jo at det er nyttig når en får flertråding i større grad.

 

Det er også som du delvis impliserer ikke slik at SMT ikke kun er til nytte for dype design men også for brede design. I det heletatt kan en grovt si at nytten av SMT er sterkt knyttet til antall in-flight instruksjoner (instruksjoner som er under prosessering, altså på et eller annet sted inni pipelinen) en har i CPUen.

 

Rykter går vel ut på at neste generasjon x86 prosessorer skal bli ett hakk bredere enn dagens Dothan CPU. Dvs. de nærmer seg Power5 bredde. Det blir umulig å opptettholde høye nok frekvenser om en skal la hardware alene stå for effektiv ILP deteksjon til en så bred prosessor derfor må en ha eksplisitt parallellitet levert fra kompilator eller programmerer. Eneste måten å gjøre det på i en seriell instruksjons strøm er å introdusere mer enn en strøm. Altså mer enn en tråd per kjerne; SMT.

Endret 15. august 2005 av Anders Jensen

[Anders Jensen]

Edit: Som nevt over er kamuflering av minneforsinkelser en mulig grunn. Kan ikke dette slå litt ut begge veier? Tenker da på tilfeller der to tråder som kjører samtidig ødelegger for hver andre (siden de deler en begrenset mengde cache). Med bare en kjerne er det greit. Siden det i svært mange tilfeller fører til et system som oppleves litt kvikkere, men med 2 kjerner blir neppe forskjellen like stor.

Joda SMT er et tve egget sverd. Det kan medføre stor gevinst på applikasjoner som er lite cache vennlige og kan medføre redusert ytelse på applikasjoner som er veldig cache vennlige, men krever mer enn ca halvparten av tilgjengelig kapasitet. (litt mer komplisert enn som så om en tar med assosiativitet og eviction og prefetch algoritmer) F.eks kan det fungere helt glimrende med to tråder som hver bruker et område mye større enn cache hvis prefetch er med på leken og båndbredden er god nok i forhold til reuse ration på det som til enhver tid ligger i cache.

 

Som regel tjener en mer enn en taper på akkurat denne effekten, men som tidligere nevnt er det en del skjulte tap ved å implementere SMT i form av lavere frekvens og økt effektforbruk.

 

Om SMT er lønnsomt eller ikke kommer ann på applikasjon, kjernearkitektur og minnehierarki. Det vil aldri finnes noe generelt fasitsvar på denne typen teknologi og ettersom utviklingen fortsetter vil fordelene og ulempene variere relativt til hverandre, men neppe i noen generell retning.

Endret 15. august 2005 av Anders Jensen

[Anders Jensen]

Har surfa litt på nettet i kveld for å forsøke å oppdatere meg etter sommerferiens slaraffenliv.. ser ikke ut som om det har vært sommerferie hos Intel. De har 17 multicore design under utvikling per dags dato. Herunder er nok dualcore regnet som multicore. Det er jo strengt tatt et spesialtilfelle av multiore.

 

De har også nettopp kommet med en endring i lanseringstidspunktet for dualcore Xeon. De er flyttet frem fra 2006 til 2005. Kommer vel neppe mye før jul. Sammen med Blackford blir det en genial server platform. Kanskje den beste i 4/8-way server markedet? Opteron vil få noe å bryne seg på det er i allefall sikkert. Er ikke sikker på om det kommer workstation konfigurasjoner av dette chipsettet.

[el-asso]

. Jeg har hørt at "oversetteren" mellom x86 og CPU'ens indre kode tar en ganske stor del av kjernen på en CPU. Tror jeg har hørt 30 eller 40% av selve kjernen (uten L2 cache). Jeg er ganske usikker på om det stemmer så jeg håper noen med peiling kan utdype dette mer.

Jepp, det bifalles, har nemlig hørt at det bare er et par prosent på en morderne CPU, så det hadde vært interessant å få dette på det rene.

Tror du er inne på noe med ett par prosent hvis en ser på die areal som går til ren decoding. Fant en sak her som gir en detaljert framstilling av "Hammer". Ikke det mest representative, men skulle likevel gi en rimelig god indikasjon. Spørsmålet er bare hvor mye som trekkes inn i forbindelse med decoding.

 

Bla ca. 3/4 ned på siden til plansjen "Opterons Instruction Cache and Decoding Pipeline". Med litt kjapp linjalbruk og prosentregning kom jeg til ca. 2% (Cache ikke medtatt). Da har jeg kun tatt med "Instruction code, decode 1 and decode 2 pipelinestages and microcode" og "Instruction decode and pack pipelinestages"

 

Edit: Ser av en artikkel på Ars at det var snakk om 30% av transistorbudsjettet for tidlig Pentium.

Intel estimated that a whopping 30% of the Pentium's transistors were dedicated solely to providing x86 legacy support.

[..]

Today, x86 support accounts for well under 10% of the transistors on the Pentium 4

Endret 16. august 2005 av el-asso

[snorreh]

Lurer på hvor lenge vi blir sittende med den allerede aldrene x86 teknologien ....

Er x86-tekonolgien så ille egentlig? eg har hørt at moderne CPUer uansett "kjører sitt eget løp" arkitekturmessig, og slenger på et par transistor på toppen for å være x86-kompatible, noen som kan komme med noe mer innsikt om dette?

Den kjernelogikken som har med x86 å gjøre utgjør mindre enn 2% av arealet på prosessorene i dag, og det er så lite at det ikke er et nevneverdig problem. Jeg synes at disse plansjene fra AMDs Dirk Meyer sier det ganske bra:

 

 

 

 

Flere her:

http://epscontest.com/presentations/05q2_a....htm?slide=34&a

Endret 16. august 2005 av snorreh