Dell på vei mot AMD?

[el-asso]

Nå er vel ikke Merom, Conroe osv tynnere kjerner, men tvert i mot bredere kjerner (4 issue i stedet for 3).

Dette er et punkt jeg gjerne skulle hatt på det rene. Jeg har sett dokumentasjon som eksplisitt nevnte 4 issue for dagens x86-64, 6 issue for paxville, 11 issue for Itanium2, er det noen som har ytterligere, evt. motstridende informasjon/dokumentasjon om dette?

5196211[/snapback]

For x86-64 se plansje nr.4 fra toppen

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2504

Note that with a 4-issue core, the new processors will actually have a higher degree of ILP than AMD's Athlon 64,

[snorreh]

Nå tyder vel markedsandelen til Intel på at disse "halvfabrikatene" fungerer rimelig bra til sitt bruk, selv om mange antakelig hadde vært like godt tjent med å gå over til konkurrenten.  Når det gjelder midlertidige løsninger er vel alt i denne bransjen midlertidige, det er bare spørsmål om graden av midlertidighet.

5195478[/snapback]

Joda, og som i alle bransjer så selger som regel kvantitetsprodukter (mindre elegante løsninger) bedre enn kvalitetsprodukter (elegante løsninger) til tross for at prisforskjellene ikke er så store.

 

Hvem som kommer med den beste totalløsningen for kundene er det kundene selv som vet best, det er vel ikke uten grunn at Opteron nå gjør det så bra?

5195478[/snapback]

Nei, denne reportasjen fra SC'05 sier det meste sånn sett:

http://www.theregister.co.uk/2005/11/22/sc_review/

At this year's conference in Seattle, Opteron boxes appeared en masse, and the users could not stop talking about the processor. AMD, for example, had myriad motherboards on display from Asian designers. Similarly, Penguin Computing told us that Opteron-based systems account for about 80 per cent of its big sales with Intel's Xeon products generating almost no interest.

[...]

(Itanium actually received more play than Xeon at the show, which you know is a horrible sign for Intel.)

 

Simply put, you couldn't escape the Opteron chatter. The chip finally looks set to capture the high performance computing wins that many predicted two years ago. These large sales translate into thousands upon thousands of processors being moved. And even away from the HPC scene, just about every server start-up looking to target the corporate market these days seems to base its systems on AMD's chip.

Endret 23. november 2005 av snorreh

[el-asso]

Hvem som kommer med den beste totalløsningen for kundene er det kundene selv som vet best, det er vel ikke uten grunn at Opteron nå gjør det så bra?

5195478[/snapback]

Nei, denne reportasjen fra SC'05 sier det meste sånn sett:

http://www.theregister.co.uk/2005/11/22/sc_review/

At this year's conference in Seattle, Opteron boxes appeared en masse, and the users could not stop talking about the processor. AMD, for example, had myriad motherboards on display from Asian designers. Similarly, Penguin Computing told us that Opteron-based systems account for about 80 per cent of its big sales with Intel's Xeon products generating almost no interest.

5196632[/snapback]

Leste den jeg også, stod vel også noe om at til og med Itanium fikk mer oppmerksomhet en Xeon.

Derfor er det kanskje ikke utenkelig at Dell virkelig vil levere AMD bokser. Tipper de gladelig ofrer "neste års" eksklusive Intel-avtale dersom de har funnet ut at det blir mer i gjenn i potten av å selge AMD.

I så fall viser det at det nytter å ha gode produkter, og at det er kundene som til syvende og sist avgjør.

[Simen1]

Til Del: Her er et par linker til:

http://www.sandpile.org/impl/k7.htm

Specific Details

72 MOP Entry ROB/ICU

18 MOP Entry Integer Scheduler

36 MOP Entry FP Scheduler

 

Instruction Decoder

Direct and Vector Path

up to 3x IA-32/Cycle

up to 3x MOPs/Cycle

up to 6x ROPs/Cycle

 

Execution Units

3x IEU (1x w/ MUL, 2x w/o MUL), 3x AGU (1x/IEU),

3x Pipelined FP (1x ADD, 1x MUL, 1x STORE)

 

Execution Speed

up to 3x Integer MOPs/Cycle

up to 6x Integer ROPs/Cycle

up to 3x FP ROPs/Cycle

Alt går opp i 3 og er beregnet på at man skal klare å holde en teoretisk instruksjonsrate på 3 instruksjoner per syklus. I praksis klarer man ikke å utnytte all parallellteten så noen sykluser er det mindre enn 3 instruksjoner som blir behandlet. Andre ganger kunen man utnyttet mer enn 4 instruksjoner per syklus. Særlig med intels HyperThreading bør det være mulig å utnytte en god del av de teoretisk maks 4 instruksjonene per syklus.

 

Her er en skisse av pipelinene i K7/K8:

http://arstechnica.com/articles/paedia/cpu...-hammer-1.ars/6

Du kan se på høyre side der at det er 3 parallelle grå pipeliner. Det står også noe i teksten om teoretisk maks 3 instruksjoner per klokkesyklus.

K7 og K8 er forresten forbløffende like på denne sentrale delen av kjernen. K8 har et par ekstra steg i pipelinen, men er ellers veldig lik K7.

K6 er derimot helt forskjellig, så denne sentrale delen av kjernen var noe som kom med K7 i 1999.

[el-asso]

Her er en skisse av pipelinene i K7/K8:

http://arstechnica.com/articles/paedia/cpu...-hammer-1.ars/6

Du kan se på høyre side der at det er 3 parallelle grå pipeliner. Det står også noe i teksten om teoretisk maks 3 instruksjoner per klokkesyklus.

K7 og K8 er forresten forbløffende like på denne sentrale delen av kjernen. K8 har et par ekstra steg i pipelinen, men er ellers veldig lik K7.

K6 er derimot helt forskjellig, så denne sentrale delen av kjernen var noe som kom med K7 i 1999.

5197058[/snapback]

Mente jeg hadde lest noe om dette en gang. Fant det her: The G4 and the K7: an architectural look at two post-RISC processors

The K7's beast of a front end can dispatch up to 3 MacroOps per cycle to any of its 9 execution units.  Since each of these MacroOps is composed of both a memory access instruction (LOAD/STORE, LOAD, or STORE) and a register-based instruction, you could claim that, in effect, the K7's front end spits out up to 6 ops per cycle -- and you'd be right in one sense.  But since this number is constrained by the fact that three of those ops would have to be address calculations, it's probably better just to talk about the K7 as dispatching 3 MacroOps per cycle.  And actually, the K7 rarely reaches this peak rate of 3 Mops per cycle.  I hear the average is around 2.5 Mops per cycle.

[Simen1]

Takk for oppklaringa. Jeg har også hørt tallet 2,5 instruksjoner per syklus i snitt. Tror det var på aceshardware i tida rundt lanseringen av K8.

 

Jeg hørte noe i samme åndedrag om at Pentium4 på den tiden lå på rundt 1,7-1,9 instruksjoner per klokkesyklus. Noe som gikk ganske godt opp i opp med den høyere klokkefrekvensen.

Endret 23. november 2005 av Simen1

[Anders Jensen]

Nå er vel ikke Merom, Conroe osv tynnere kjerner, men tvert i mot bredere kjerner (4 issue i stedet for 3).

Dette er et punkt jeg gjerne skulle hatt på det rene. Jeg har sett dokumentasjon som eksplisitt nevnte 4 issue for dagens x86-64, 6 issue for paxville, 11 issue for Itanium2, er det noen som har ytterligere, evt. motstridende informasjon/dokumentasjon om dette?

5196211[/snapback]

6 issue for paxville må være bygd på en missforståelse. Jeg har faktisk sett denne versert en runde på Ace's også. Det dreier seg om to kjerner på 3 issue hver. Det er 6 issue på samme vis som to 2-WD biler i samme garasje bør ansees som en 4-WD.

 

Ser forresten at tråden snor seg omtrent som forutsett The usual suspects bedriver river dance med høye kneløft i salaten.

Endret 23. november 2005 av Anders Jensen

[el-asso]

Hvem sier at Dell ikke selger AMD prosessorer?

 

KLIKK

 

Nuvel

[snorreh]

Nå er vel ikke Merom, Conroe osv tynnere kjerner, men tvert i mot bredere kjerner (4 issue i stedet for 3).

Dette er et punkt jeg gjerne skulle hatt på det rene. Jeg har sett dokumentasjon som eksplisitt nevnte 4 issue for dagens x86-64, 6 issue for paxville, 11 issue for Itanium2, er det noen som har ytterligere, evt. motstridende informasjon/dokumentasjon om dette?

5196211[/snapback]

6 issue for paxville må være bygd på en missforståelse. Jeg har faktisk sett denne versert en runde på Ace's også. Det dreier seg om to kjerner på 3 issue hver. Det er 6 issue på samme vis som to 2-WD biler i samme garasje bør ansees som en 4-WD.

5198145[/snapback]

Da kan det være verdt å merke seg at 11-issue for Itanium2 også er en velkjent missforståelse, ettersom det korrekte faktisk er maks 6-issue:

http://www.aceshardware.com/forums/read_po...45458&forumid=1

The I2 can issue a maximum of 6 instructions per cycle not 11. It can issue them to 11 possible execution units.

Hvor mange den i praksis virker likevel å være en god del lavere, kanskje mindre enn 2 på heltallsoperasjoner?

 

Slikt kan være verdt å ta med i beregningen mhp. påstanden om 4-issue for "Merom" & co. også - det tallet som Intel oppgir vs. det tallet som gjelder i praksis. Det er som kjent stor forskjell mellom teoretisk og reell ytelse, kanskje spesielt for Intel-prosessorer som stort sett bare gjør det best i syntetiske tester.

Endret 24. november 2005 av snorreh

[Del]

Her er det åpenbart noen misforståelser ute og går, issue og instruksjoner er to forskjellige ting. For Itanium2 gjelder 11 issue, 6 instruksjoner. Tror også Simen og el-asso blander begreper her. Kanskje du har en oppklarende link her Anders?

[Anders Jensen]

Nå er vel ikke Merom, Conroe osv tynnere kjerner, men tvert i mot bredere kjerner (4 issue i stedet for 3).

Dette er et punkt jeg gjerne skulle hatt på det rene. Jeg har sett dokumentasjon som eksplisitt nevnte 4 issue for dagens x86-64, 6 issue for paxville, 11 issue for Itanium2, er det noen som har ytterligere, evt. motstridende informasjon/dokumentasjon om dette?

5196211[/snapback]

6 issue for paxville må være bygd på en missforståelse. Jeg har faktisk sett denne versert en runde på Ace's også. Det dreier seg om to kjerner på 3 issue hver. Det er 6 issue på samme vis som to 2-WD biler i samme garasje bør ansees som en 4-WD.

5198145[/snapback]

Da kan det være verdt å merke seg at 11-issue for Itanium2 også er en velkjent missforståelse, mens det korrekte er maks 6-issue:

http://www.aceshardware.com/forums/read_po...45458&forumid=1

The I2 can issue a maximum of 6 instructions per cycle not 11. It can issue them to 11 possible execution units.

Hvor mange instruksjoner den i praksis klarer å kjøre hvert sekund virker likevel å være en god del lavere, kanskje bare 2 på heltallsoperasjoner?

5199842[/snapback]

Dette er imidlertid en annen type missforståelse, gitt at PD har rett. Det er ingen tvil om at I2 har 11 issueports. Det er heller ingen tvil om at den har en maksimal sustained IPC på 6 instruksjoner pga decode bandwidth på 2 bundler = maximalt 6 instruksjoner. Alt dette kommer klart frem i I2 dokumentasjonen. Jeg har imidlertid ikke sett noen dokumentasjon som viser helt klart hvilke begrensninger som ligger rundt bruk av de 11 issueports som finnes i I2. Jeg har forsøkt å få PD til å forklare dette tidligere, men uten hell (kort sagt sa han vel "sånn er det bare", et komplett uakseptabelt svar for mange og enhver skulle jeg tro). Det virker ikke som om han vet det. Det knytter seg noe usikkerhet til instruksjonsbufferet som kan holde 12 ferdig dekodede instruksjoner og befinner seg rett før issue steget i pipelinen.

 

Når det gjelder reelt oppnådd IPC så er det typisk snakk om 50% utnyttelsesgrad. dette varierer nokså mye fra applikasjon til applikasjon. De tallene jeg har sett ligger ofte mellom 2.5 og 3.5 IPC med noen avvik hist og her. Det er f.eks eksempler på kode hvor en oppnår 5+ IPC. Det er neppe noen CPU som vil slå I2 i de tilfellene den oppnår slike mengder IPC. Dagens OOE kjerner ligger vel på 2.5 IPC i best case med unntak av Power5 som ligger noe høyere. Merom vil vel legge seg i dette sjiktet også.

 

Eksperimentelle kompilatorteknikker har vist at det vil være mulig å oppnå 3+ IPC for nesten hvilken som helst kode (unntak for OLTP type minnebruk selvfølgelig) på dagens I2 implementasjon. Fremtidig integrering av minnekontrolleren vil jo også bidra til å øke IPC en del, igjen dette vil avhenge mye av applikasjonen som kjøres.

Endret 24. november 2005 av Anders Jensen

[el-asso]

Her er det åpenbart noen misforståelser ute og går, issue og instruksjoner er to forskjellige ting. For Itanium2 gjelder 11 issue, 6 instruksjoner. Tror også Simen og el-asso blander begreper her.

5199901[/snapback]

Hææ? Blander hvor da?

[Spirograf]

Hehe, her sporer det av som vanlig... Litt morsomt at det er brukermoderatorer som sporer av

 

Hvis dette er sant så får vi si velkommen etter til Dell.

[Del]

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2504[/url]

Note that with a 4-issue core, the new processors will actually have a higher degree of ILP than AMD's Athlon 64,

5196616[/snapback]

Her.

 

Økning i antall issue gir ikke nødvendigvis flere instruksjoner pr. syklus, der er det vel fortsatt tre maksimalt, og det skjer endel mellom issue ports og faktisk utføring av instruksjoner, jeg har ikke full oversikt her selv, men skal prøve å nøste litt opp i det ved første anledning.

 

Apropos Itanium2 er dette et enkelt regnestykke intuitivt, multipliser antall instruksjoner pr. syklus med frekvens på prosessoren. Da ser man også fort hvorfor Xeon med 3.8GHz og maks. 3 instruksjoner pr. syklus, kan få meget god ytelse hvis man klarer å få prosessoren til å yte maks hele tiden (hvilket selvfølgelig er utopi for de fleste tilfeller, men på noe kode kan faktisk Xeon sparke skikkelig).

[Anders Jensen]

Helt korrekt. Merom kunne hatt høyere IPC enn K8 selv ved hypotetiske 3 issue for Merom og den kan ha lavere IPC enn K8 selv med sine 4 issue. Det er ikke noen direkte sammenheng mellom issue bredde og praktisk ytelse per klokkeslag. PM, P4 og K8 er jo alle 3 issue. Ingen av de har særlig mange likheter når deg gjelder oppførsel på diverse kode.

 

PS var ikke K5 eller K6 4 issue?

[el-asso]

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2504[/url]

Note that with a 4-issue core, the new processors will actually have a higher degree of ILP than AMD's Athlon 64,

5196616[/snapback]

Her.

 

Økning i antall issue gir ikke nødvendigvis flere instruksjoner pr. syklus, der er det vel fortsatt tre maksimalt,

5200578[/snapback]

Er klar over dette, ser at jeg ikke burde ha quotet Anandtechs forenklede beskrivelse.

 

Vedr. økt IPC for Merom er muligens Micro-Op fusion og Trace Cache noe en bør ta en nærmere titt på.

Endret 24. november 2005 av el-asso

[Anonym123456789]

Jeg håper dette er sant. Hvis Dell begynner å selge store mengder AMD-maskiner, vil AMD måtte øke produksjonskapasiteten og bedre konkurranseevnen etc. etc.. Poenget, selv om andre kan si det bedre enn jeg gjør (og for alt jeg vet kan ha sagt det tildilgere i tråden), er at CPU-er blir billigere.

[Del]

Har endelig fått begynt nøste opp litt, uten at jeg har full oversikt ennå. Burde egentlig hatt dette i en egen tråd skikkelig OT.

 

Når det gjelder tidlig netburst, før AMD64, hadde disse fire issue porter. Med AMD64 fikk de seks. I likhet med Nocona har Paxville seks issue porter pr. kjerne. Itanium2 har som kjent elleve. Begrensningen i issue ser ut til å ligge i trace cache, som for netburst kun kan gi tre micro-ops pr. cycle, men dette er heller ikke hele sannheten, siden du har en buffer som kan gi ytterliger micro-ops. Så hvis man skal karakterisere Nocona/Paxville som 3 issue er antall issue porter villedende, det er i såfall trace cache som legges til grunn, men dette er heller ikke helt riktig siden du fra buffer kan få ytterliger micro-ops issued pr. cycle. Helhetsbildet fra issue til execution blir for omfattende for meg å gi nå (har for dårlig oversikt til å summere det med få ord), men god dokumentasjon finnes her.

 

Dessverre ble kostnaden ved å sjekke opp dette litt i dyreste laget for meg, jeg kan ikke delta i diskusjoner rundt Merom/Woodcrest/Conroe lenger.

Endret 26. november 2005 av Del

[Anders Jensen]

Begrepene "issue port" og "issue width" er ikke nødvendigvis relaterte. Kan ikke si jeg har gjort noe dypdykk i denne delen av arkitekturen. For x86 har en jo i tillegg decoding som forkludrer disse regnestykkene en del.

Endret 26. november 2005 av Anders Jensen

[Osse]

Altså at det går an av Dere å prate bort et slikt seriøst emne, med tull om issus og slikt, fysj.

 

Nå, egentlig ikke, er forbauset over kunnskapsnivået til Dere.

 

Egentlig så skulle du Anders/Del/Lasso/Siemen ha laget en artikkelserie hvor dere forklarer litt om diverse begrep som er ukjent for oss allminnelige nerder.

 

Men uansett, jeg ser ingen god grunn til å ønske et samrøre hos Dell mellom AMD og Intel, da dette sikkert vil føre til at Dell taper sine rabatter, og det vil være synd om Intels siste skanse skulle falle.

 

Forbeholder meg retten til å fortsette hate intel og dermed Dell, dette aldeles uten å ha noen logisk forklaring. Og siden jeg hater Dell misnt like mye som jeg hater Intel, så vil det gå ut over min lojalitet til AMD, og da taper de minst, ja minst 15 cpu'er i salg pr år. Vil garantert ta rotta på AMD en slikt tap. (blir jo nøyd til å bygge på via sine cpu'er, huff)

 

AMD er i hardt vær, taper 20 salg hos snekkern pga at de mobber Intel, og risikerer å tape salg fra meg pga , uforskammete rykter om samrører mellom Dell og AMD. Dette blir det trøbbel utav

Endret 28. november 2005 av Osse