Firedoble AMD-prosessorer i 2007?

[snorreh]

De som gjør det vil selvsagt kunne utnytte flerkjerne i 2007 slik de kan utnytte SMP dag og kanskje enda litt bedre. Disse programmene er imidlertid typisk server programmer. Beste unntak er rendering.

De fleste tyngre beregningsverktøy innen bl.a. CAD, CAE og CFD utnytter SMP idag, men også rendring, enkoding og spill vil etterhvert utnytte SMP bedre. Flerkjerne-prosessorer kommer utvilsomt til å ha en dramatisk innvirkning på utviklingen av flertrådete programmer, det er jeg ganske sikker på.

 

For det første har jeg ikke antydet at k8 sliter med dårlig IPC. Det jeg snakker om er en langt mer generell trend. Det er mange som mener at superskalare arkitekturer ikke kommer til å bli særlig bredere enn k8 og Dothan er. Årsaken er at det blir for kostbart for prosessoren å utforske slike mengder ILP. Da er eneste forbedringspotensiale å øke frekvensen eller øke antall kjerner. "Diminishing returns" slår ofte inn hardt allerede ved øking fra en til to kjerner. Det er veldig avhengig av programmet. Selvsagt finnes det programmer som kan kjøres på clustre med til sammen flere tusen kjerner, men disse representerer bare et lite fåtall.

Dette blir bare ren spekulering fra din side, den som lever får se hva som egentlig skjer

 

Ellers er det selvsagt både fint og naturlig at mer og mer blir integrert. Det kommer riktig nok ann på hva en ønsker å vektlegge. Tror kanskje Power5 er et bedre eksempel på hva som er mulig å gjøre med integrering enn Alpha. Sistnevnte er bare smågutt i forhold.

Ikke enig i at Alpha er noen smågutt sammenlignet med Power5. Det er omtrent som med Concorde, der Alpha også representerte bedre teknologi men ble ofret på bekostning av eldre og dårligere/billigere teknologi.

 

Så, ja det er fortsatt forbedringspotensiale for superskalare arkitekturer, men x86 har alt for mange ulemper heftet ved seg til å kunne oppnå samme ytelse som IBM Power på tilsvarende produksjonsprosess. Mangelen på registre er kanskje en av de alvorligste. 16GPR's setter en stor bremse for prosessorens mulighet til å utforske ILP.

Vel, til forskjell fra Power så doblet faktisk AMD64 antall registre (fra 8 til 16) når de gikk fra 32-bit til 64-bit. Dette betyr at x86-systemer vil merke en større ytelsesforbedring av å gå fra 32-bit til 64-bit enn for de fleste andre oppdaterte 64-bits arkitekturer.

Endret 16. august 2004 av snorreh

[snorreh]

Ser ellers AMD velger en liknende løsning som Intel med delt L2 cache (rykter sier Intel gjør det den veien, men med vesentlig mer cache) og en arbiter bus (i dette tilfelle sikkert Hyper-Transport, som utvilsomt vil markedsføres som noe "mer og bedre" enn en annen minst like egnet bus ).

Feil, AMD sin dual-kjerne vil ikke ha delt L2 cache som betydelig reduserer ytelsen. Ifølge VR-Zone så vil hver kjerne på AMD sin dual-kjerne prosessor ha 1MB L2 cache:

http://www.vr-zone.com/?i=1123

The Dual core has up to 1MB L2 cache per CPU, up to 3 HT link operating at 1Ghz max and a shared northbridge registers with one APIC per core.

Så vidt jeg kan se av siteringen din så presiserer ikke VR-Zone om det er 1MB dedikert per CPU eller 1MB delt per CPU.

Ok, men ifølge Anandtech har hver kjerne L2 cache som er dedisert og ikke delt:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2081

Although AMD isn't commenting on any of the details of the implementation, it appears as if the first dual core Opterons are basically two Opterons connected together on a single die - meaning each core has its own L2 cache

 

Jeg skjønner heller ikke hvorfor det å dele 2MB L2 cache skal være så mye mer ineffektivt enn å ha 2x1MB dedikert per CPU. Jeg kan godt tenke meg situasjoner der det er gunstig å ha fleksibiliteten av mengden L2 cache som skal prioriteres til hver CPU. Og situasjoner der "cache coherency" vil fungere bedre med delt L2 cache. Uten å si noe sikkert om hva som lønner seg best totalt sett så synes jeg det er verd å undersøke litt nærmere først. (Noe trolig AMD jobber med i utviklings'laben sin nå)

Delt cache er lite effektivt når såkalte cache-miss inntreffer, ref. HyperThreading. For flere detaljer om dette, samt om AMD sin flerkjerne-prosessor så foreslår jeg at du ser på dette:

 

Athlon 64 and Opteron dual-core explained

The great advantage of dual-core over HyperThreading is that both cores have their own cache. It means that the only contention is over access to main memory and HyperTransport. Provided the level 2 cache is a decent size for each core, that contention should be kept to a fairly low level. But should is the operative word. Intel's HyperThreading should have had a significant impact on performance but that impact turned out to be in the negative rather than the positive that Intel had hoped for. That's not to say that HyperThreading won't start making improvements in future applications that are aware of the technology.

 

However, AMD will gain from HyperThreading aware applications too as Intel designed the technology to appear as though there were dual processors. A dual-core processor will do exactly the same so the both Intel and AMD are likely to reap any benefits from the move.

Endret 16. august 2004 av snorreh

[snorreh]

Sjefen i Tyan, Symon Chang, røper flere detaljer om K9 i dette intervjuet:

http://www.digitimes.com/news/a20040726PR202.html

Q: We’ve seen the four-way server offerings from Tyan, including the one launched last year, and this year’s version launched here at Computex. Does Tyan have any plans for building larger platforms? Does Tyan have an eight-way in the works?

 

Chang: We do have an 8-way server board, which is primarily a four-plus-four, but we’re not offering that right now with the present chipset. I am aware that our competitors are doing that, but we’re going to do that in the PCI Express generation. We felt that the current chipset does not have the right I/O capabilities and so we might as well wait until the new ones come out.

 

Around 2006, when the market moves to AMD’s next generation of chips, you will be able to go over 8-way. What I mean is that with eight sockets, and dual cores, you then have sixteen processors, but with K9, you’ll see it go over that. I think we’ll see a significant increase in the amount of crossbar switches in the CPU. I’m not up on all the minute details, but you’ll be able to go over 60 processors without adding any external crossbar chips. We can do all that within the structure that is being currently created. The crossbar bar chip is the standard in the mainframe business whether it is for the Xeon, Opteron or other processors. There are a couple of versions of the crossbar chip today, but I don’t think that anyone is currently using them for anything in the generic market; these solutions are really only for the mainframe market. Today’s mainframe market with computers from IBM or Sparc will be using up to and over 128 processors, with chips such as IBM’s 390 microprocessor. These machines are starting around US$1 million.

[Cell_v14]

Dette blir jo et must for servere men håper det kommer til og skje det samme med grafikkkort siden spill blir mere og mere complex (grafisk sett).

[sveinsel]

Det er altså taket for temperaur som definitivt synes vere nådd med dagens elektro-teknologi. Nå må noen gjøre noen grep slik at CPU-core kan kjøles fra begge sider ..... eller noe .....

[Tanguero]

Det er ennå en del spill som er en del CPU-begrenset. Bl.a. FarCry og Doom3 er begrenset til rundt regnet 70-80FPS. Dvs. at du ikke får høyere FPS uansett hvor lavt du setter oppløsninga. HL2 kan fort vise seg å også bli CPU-begrenset. Om den potensielle ytelsen kan dobles ved å kjøre to tråder så tviler jeg ikke på at spillutviklerene kommer til å ta i bruk flere tråder i fremtiden.

 

D3 er etter det jeg vet låst på 60fps internt i motoren, så "hastighet" ut over 60 fps har ingen betydning for spillhastigheten, kun rendring i skjermkortet. Ytelsesproblemet i dagens spill er i all hovedsak grafikkrelatert og der vil ikke en ekstra prosessor hjelpe.

En 486 vil naturligvis skape cpu-begrensning i D3, men med utgangspunkt i maskiner i gaming-kategorien er det definitivt skjermkort/minnehastighet som er flaskehalsen slik jeg ser det.

 

Den ytelsen man noen ganger kunne se i Quake3 med eldre smp maskiner var etter det jeg kan huske relatert til at det ble benyttet software-rendering (Q3 ble lansert da TNT/TNT2 var et vanlig skjermkort). I dag produseres grafikken "utelukkende" av skjermkortet, prosessoren styrer AI, fysikk, posisjonering, lyd(i D3) etc

 

Men som jeg antydet tidligere ligger potensialet for multiprosessering i videreutvikling av AI, og hendelser som foregår utenfor det spilleren har på skjermen. Et eksempel på dette kan være i RTS spill som i dag har relativt forutsigbare AI opponenter hvor kraftigere motstand er det samme som at de jukser mer med ressurser/produksjon og ikke følger samme regler som deg. En AI som har et stort utvalg av avanserte angrepsstrategier å ta av vil gi en mye bedre spillopplevelse.

 

Oppsummering: Ja, jeg håper spill i fremtiden støtter SMP, men ikke forvent at denne ekstra ytelsen vil gjøre noe for bedring av ytelse/grafikk.

(skulle gjerne ønske D3 med SMP jeg ettersom jeg sitter på dual 2400+)

 

 

Edit: Som andre nevner: smp på skjermkort (evt SLI) vil være mer avgjørende for grafikk/ytelse slik vi kjenner begrensningene i dag

Endret 16. august 2004 av Tanguero

[Knick Knack]

snorreh: Jeg vet at du ikke ønsker å være enig med meg, men nå har du beskylt med for missforståelser og spekulasjoner tre ganger bare i dag uten å konkret bevise at det medfører riktighet. Noe jeg tviler på at du klarer da jeg mener å vite å ha holdt meg på det tørre. Kan du vennligst slutte med det?

 

btw: Hva er vel så stort med at x86 har økt fra 8 til 16 GPR's når alle RISC arkitekturer har hatt 32 GPR's siden de ble utviklet en gang mellom 1967 og 1994, alt ettersom hvilken en ser på?

 

The x86 isn't all that complex - it just doesn't make a lot of sense.

En kan jo spekulere rundt dette og missforstå så mye en måtte ønske.. og det kan jo fort bli en del!

 

Ellers:

Ser det er en diskusjon om hva som er best av dedikert og delt cache her. Det er sikkert en komplisert studie og jeg vil tro svaret vil være mye avhengig av hva en ønsker å optimalisere for. Jeg kan imidlertid fortelle at L1 cache er per i dag så integrert i prosessorkjernen at det kan sies å være en del av den. Skal en endre L1 cache så vil det medføre endringer i selve kjernen også. (dette er ikke spekulasjoner, jeg anbefaler Hennessy & Patterson for videre utdyping)

 

L2 cache er som oftest langt løsere knyttet til kjernen og her kan det i enkelte tilfeller være fordelaktig å velge en løsning med delt cache for dual/multicore systemer. Fordelen med delt L2 cache er bedre utnytting av cache som enten kan utnyttes ved å implementere mindre total cache mengde og derme mindre die, eller beholde samme total mengde og dermed øke cache hit rate. En slipper også det ekstra båndbreddebehovet, forsinkelsen og transistorer/kompleksitet som må innføres ved dedikert cache og cache coherency (CC) protokoller. (ekstra forsinkelse kun i de tilfeller hvor CC lager krøll.) Den rimelige opplagte ulempen er at en får en mer komplisert krets mellom kjernene og cache som vil introdusere større forsinkelse og kan bli en båndbredde flaskehals, selv om jeg betviler at båndbredde kommer til å bli et problem i praksis. Av de systemene jeg har sett og hørt rykter om så er det nesten bare systemer optimalisert for desktop og laptop hvor delt L2 cache blir vurdert pga redusert areal og effektforbruk. For high end systemer er dedikert L2 cache absolutt mest vanlig.

 

L3 cache er nesten alltid implementert eller foreslått implementert som delt eller ikke brukt i det hele tatt. Dette pga areal og kostnads hensyn. Det er jo ofte store mengder L3 cache en implementerer når en først velger å bruke det.

 

L4 cache er aldri på cpu die eller CPU modul så vidt jeg vet, men er plassert i nettverket som knytter prosessorer og minne sammen i noen av de systemene som er så store at dette er noe å vurdere. Typisk med 16 CPU moduler og oppover. Denne er derfor i sin natur delt.

 

Simen1: Tror nok du har rett i at AMD med quad core på 65nm flagger at de har forventninger til sin 65nm prosess. Den ser da også svært lovende ut på papiret med SS-SOI. I motsetning til Intel som fortsatt satser på vanlige bulk transistorer.

 

Nå vet jeg ikke mye om CMOS profeter, men vet at Toshiba har vist 22nm bulk transistorer som bare var marginalt unna det offisielle industri kravet til 22nm prosesser. (lekasjen var langt bedre enn kravet, men de ledet ikke nok strøm i "på" tilstand) Gjennombruddet skyldes i hovedsak bruk av noe slags nitrogen - Si forbindelse jeg har hørt en del snakk om fra flere kanter. Ser lovende ut. Kombinert med SOI eller FDT og raised drain/source, SS, osv. kan det bli virkelig bra. Moores lov vil nok bli fulgt i enda et tiår fra nå.

Endret 16. august 2004 av Knick Knack

[Simen1]

Athlon 64 and Opteron dual-core explained

There are definite advantages to everything being on a single chip, most noticeably a reduction in latency, but it's unlikely that a system with one dual-core Opteron processor would ever manage to outpace a system with two single-core Opterons. The latter has two lots of main memory so it simply doesn't have the same contention issues.

Nåja, har de nå egentlig så rett i dette? Vi har jo sett at det å addere 1 minnekanal til Athlon64 (Socket754->939) ga minimale ytelsegevinster (~5% i snitt). Vil det da bli så veldig mye tap av å halvere minnetilgangen per Opteronkjerne fra 2 til 1 minnekanal da? Ok, la oss bare for tankeeksperimentets del si at det gir ~5% lavere ytelse jevnt over.

 

Nå vet vi jo også at minnetilgang fra et 2x single-operon oppsett delvis begrenses av at det noen ganger trengs data fra minnet som er tilkoblet den andre CPU'en. Dette øker den gjennomsnittlige latencyen i forhold til et 1x Opteron-oppsett fordi man innfører ett "hopp" via HT-bussen. Hvis man integrerer begge kjernene på en CPU så vil man unngå dette håppet totalt. Uansett om OS'et er NUMA-aware eller ikke. Med dagens 2x singel Opteron så vil selv et NUMA-aware OS gi noe økt gjennomsnittlig latency. For ikke å snakke om alle de ikke-NUMA-aware OS'ene som veldig ofte brukes på dagens dual Opteron-oppsett. Man kan jo spørre seg om hvor mye det ekstra hoppet har å si for ytelsen, men la oss for tankeeksperimentets del anta det kun utkjør et ~5% ytelsetap.

 

Hvis vi så summerer de to motvirkende effektene av å ha CPU på samme kjerne så ser jammen tankeeksperimetet ut til å gi omentrent samme ytelse på de 2xsingle Operon som på 1xdual operon. Er det noe jeg har glemt å ta med i betrakningen? Noen som mener at den ene effekten er mye sterkere enn den andre slik at det blir en forskjell? Evt. hvilken?

[Knick Knack]

Athlon 64 and Opteron dual-core explained

There are definite advantages to everything being on a single chip, most noticeably a reduction in latency, but it's unlikely that a system with one dual-core Opteron processor would ever manage to outpace a system with two single-core Opterons. The latter has two lots of main memory so it simply doesn't have the same contention issues.

Nåja, har de nå egentlig så rett i dette?

Det vil være 100% applikasjons avhengig! krever den lite minnebåndbredde så vil det være noe feil. Krever den mye så vil det være riktig. I snitt vil det nok være riktigere enn å påstå at dual core er raskest.

[snorreh]

btw: Hva er vel så stort med at x86 har økt fra 8 til 16 GPR's når alle RISC arkitekturer har hatt 32 GPR's siden de ble utviklet en gang mellom 1967 og 1994, alt ettersom hvilken en ser på?

For x86 så representerer en dobling av registrene en stor forbedring, spesielt med tanke på enda bedre ytelse. Ser man på andre arkitekturer som har gått fra 32-bit til 64-bit, f.eks. PPC G4 til PPC G5, så ble ikke antall registre økt og dermed blir heller ikke ytelsesgevinsten like stor sammenlignet med x86-64/AMD64. For flere detaljer om dette så les denne glimrende artikkelen:

http://www.devx.com/amd/Article/16101

 

The x86 isn't all that complex - it just doesn't make a lot of sense.

En kan jo spekulere rundt dette og missforstå så mye en måtte ønske.. og det kan jo fort bli en del!

Linus Torvalds sa det glimrende her:

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

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.

Endret 16. august 2004 av snorreh

[Knick Knack]

btw: Hva er vel så stort med at x86 har økt fra 8 til 16 GPR's når alle RISC arkitekturer har hatt 32 GPR's siden de ble utviklet en gang mellom 1967 og 1994, alt ettersom hvilken en ser på?

For x86 så representerer en dobling av registrene en stor forbedring, spesielt med tanke på enda bedre ytelse. Andre arkitekturer som har gått fra 32-bit til 64-bit, f.eks. PPC G4 til PPC G5, så ble ikke antall registre øket og dermed blir heller ikke ytelsesgevinsten like stor sammenlignet med AMD64.

Jeg ser jo at x86 muligens kan knappe inn en smule av det ekstreme forspranget Power5 har oger x86 med dette, men det er vel neppe å karakterisere som viktig for den store sammenhengen.

 

Linus har forøvrig en godt poeng. (det eneste gode forøvrig) Men det er i ferd med å vannes ut grunnet andre alternativer som blir stadig mer nyttige og ikke minst at porting stadig blir enklere grunnet bedre verktøy. og at høynivå programmering er det eneste som er utbredt i dag og derfor gjør programmene arkitektur uavhengige før kompilering.

[Simen1]

Det er altså taket for temperaur som definitivt synes vere nådd med dagens elektro-teknologi. Nå må noen gjøre noen grep slik at CPU-core kan kjøles fra begge sider ..... eller noe .....

Intel hadde en ide om å kjøle fra begge sider for en del år siden. Det endte i Slot1-CPU'ene, og AMD fulgte etter trenden og lanserte SlotA. Ingen av delene må sies å være særlig suksessfulle når det gjelder kjøling fra baksiden av CPU'en. Hele greia bare kostet mer enn nødvendig, lagde støy-problemer for FSB (pga slot'en), og kjølingen ble kun minimalt forbedret. Selv om kjøling fra to sider er litt mer effektivt ble Slot-CPU'ene raskt ofret på grunn av de andre svakhetene.

 

Men de har andre måter å løse kjøleproblemet på: Samme metode som når man tar en vanlig CPU og "forvandler" den til en mobil CPU. "Forvandlingen" er ikke mer avansert enn at de underklokker litt og dermed kan senke spenningen. Dette kan også gjøres for dual-CPU. Forvent derfor at de raskeste dualcore CPU'ene er noe lavere klokket og går på noe lavere spenning enn de raskeste singlecore CPU'ene. Quadcore vil nok gå på ennå lavere spenning og hastigheter.

 

Antatt eksempel:

singlecore toppmodell: Opteron 2,4GHz 1,50V 89W

dualcore toppmodell: Opteron 2,0GHz 1,35V 89W

[snorreh]

Linus har forøvrig en godt poeng. (det eneste gode forøvrig) Men det er i ferd med å vannes ut grunnet andre alternativer som blir stadig mer nyttige og ikke minst at porting stadig blir enklere grunnet bedre verktøy. og at høynivå programmering er det eneste som er utbredt i dag og derfor gjør programmene arkitektur uavhengige før kompilering.

Ja, men problemet er at mye industristandard programvare er skrevet i f.eks. Fortran som er mye vanskeligere å porte til en annen arkitektur sammenlignet med f.eks. Java. Hvis man ikke bruker Java, så blir porting til helt nye arkitekturer derfor ofte veldig tidskrevende og kostbart. Hovedgrunnen til at porting av operativsystem til x86-64 har tatt så lang tid skyldes ene og alene lavnivå-kode, f.eks. drivere som er skrevet i maskinkode. Det hadde vært genialt med programmer som kunne kjørt plattformuavhengig, men vi er ikke der på langt nær enda selv om Microsoft og SUN nå nylig har begravd stridsøksa mhp. Java vs. .NET.

Endret 16. august 2004 av snorreh

[pskard]

Tror og funksjonen er disablet idag, har testet på HT P4'en men der var det null forskjell.

SMP ble kuttet ut i QIII for lenge siden da det var så få som brukte den og det medførte langt mer utvikling/vedlikehold. Du må bruke en gammel versjon av QIII (ikke patchet) for å få testet effekten av singel vs dual i QIII.

 

Ellers vil jeg påpeke at AMD har snakket om dualcore lenge. Hele K8 ble laget med hensyn til å lage dualcore-versjoner. Hvem som kommer først ut med det av AMD og Intel skal jeg ikke spekulere om da begge selskaper snakker mye og har masse forsinkelser.

[Gunnar_]

SMP ble kuttet ut i QIII for lenge siden da det var så få som brukte den og det medførte langt mer utvikling/vedlikehold. Du må bruke en gammel versjon av QIII (ikke patchet) for å få testet effekten av singel vs dual i QIII.

[OT]

Ble den kuttet før hw.no's dual tester? Nudge nudge, wink wink.

[/OT]

[pskard]

[OT]

Ble den kuttet før hw.no's dual tester? Nudge nudge, wink wink.

[/OT]

Tror vi hadde en test av dual Celeron 366 @ 550 eller noe sånt hvor den var med, men det er lenge siden...

 

Uansett sier ikke QIII noe om noe som helst i dag. Et gammelt spill som svært få bruker og alle kort kan kjøre med massevis av FPS.

[Gunnar_]

Jeg mener dual 760 MP/MPX testen som ikke ble tatt imot så altfor positivt, men det er så OT at det er ingen vits å svare engang. Ca 2+ år siden.

[snorreh]

Jeg mener dual 760 MP/MPX testen som ikke ble tatt imot så altfor positivt, men det er så OT at det er ingen vits å svare engang. Ca 2+ år siden.

Tenker du på denne testen?

http://www.hardware.no/tester/cpu/athlonmp_2400/index.html

 

Hvor man utelukkende basert på en test av spillet Commanche 4 kom frem til følgende:

Konklusjon: Dual-systemer er ikke noe for en "hardcore gamer".

- Lav ytelse i spill.

[Gunnar_]

Det er mye å velge mellom

Jeg mente denne:

http://www.hardware.no/tester/cpu/mp_xp_p4/index.html

 

Det finnes visse spesialtilpassede dual-CPU måleprogrammer vi kunne kjørt på vårt dual MP 2000+ testsystem, men disse testene fungerer kun på dual-systemer. Det hadde dermed blitt litt meningsløst, siden vi ikke hadde hatt noe å sammenligne med.