Stadig nærmere dobbelkjerne

[gamer73]

Vel..dobbelt kjerne hjelper jo ikke i spill noe særlig da....eller?

 

Og da blåser jeg i dobbeltkjerne. Har Xeon dobbeltkjerne på jobben. To 1.7 Ghz. Men jeg tror den suger til spillbruk.

[ATWindsor]

Vel..dobbelt kjerne hjelper jo ikke i spill noe særlig da....eller?

 

Og da blåser jeg i dobbeltkjerne. Har Xeon dobbeltkjerne på jobben. To 1.7 Ghz. Men jeg tror den suger til spillbruk.

Direkte vil den neppe hjelpe noe særlig til spill nei (ihvertfall ikke med det første). En fordel (ihvertfall for mitt bruk) er at man kan ha opp masse programmer samtidig, uten at det går på bekostning av spillet. (dvs litt mindre ram får du antakelig).

 

AtW

[Knick Knack]

men har også halve minnebåndbredden av et Opteron system. (Om en anntar at Opteron kan bruke DDR400)

Det er heller ikke noe problem, siden minnebåndbredden ikke representerer noen flaskehals i dag.

Jeg har heller ikke sagt at det vil bli noen generell flaskehals. Det er imidlertid en del programmer som er båndbreddegbegrenset, også på dagens Opteron og Xeon systemer og de vil bare få det værre når dual core kommer. Dvs. Ytelsen går nok ikke ned på en per sokkel basis, men den går ikke opp heller. På Xeon baserte systemer må en faktisk halvere antall sokler per FSB for å ikke redusere ytelsen per sokkel for slike programmer. Det er derfor Blackford og Twin Castle chipsettene med dual FSB og FB-DIMM kommer. 28.8GB/s minnebåndbredde på deling til 2 x sokkel (6.4GB/s hver), 2 x GPU (8GB/s hver), samt at DMA fra disk gjerne tar noe innimellom... blir heftig! og alt dette med ypperste stabilitet takket være FB-DIMM.

 

Og ja, selvsagt kan Opteron benytte DDR400 for det er jo nettopp det jeg bruker på mitt system

Det kommer ann på hva systemet skal brukes til. SUN leverer så vidt jeg vet ikke Opteron systemer med DDR400 minne og det er i alle fall helt uaktuelt å bruke slikt i servere. Det er heller ikke tilfeldig at Intel gikk over til DDR2-400 før de inførte 400"MHz" minne. DDR400 er ikke ansett for å være stabilt nok til servere. Det var derfor JEDEC ikke ville godkjenne det. Nå ble DDR400 likevel trumfet gjennom til bruk i desktop og AMD fant det også godt nok for arbeidsstasjoner. Det gjorde de sikkert rett i, men som sagt så er DDR400 ikke egnet til servere.

Endret 10. desember 2004 av Knick Knack

[snorreh]

Har Xeon dobbeltkjerne på jobben. To 1.7 Ghz.

Jobber du hos Intel da eller, for såvidt jeg vet så kommer ikke dobbelkjerne Xeon før i 2006. Jobben din har sikkert dual-prosessor Xeon, og det er ikke det samme som dobbelkjerne siden der så befinner begge prosessor-kjernene seg på samme sokkel.

[snorreh]

Det er heller ikke noe problem, siden minnebåndbredden ikke representerer noen flaskehals i dag.

Jeg har heller ikke sagt at det vil bli noen generell flaskehals. Det er imidlertid en del programmer som er båndbreddegbegrenset, også på dagens Opteron og Xeon systemer og de vil bare få det værre når dual core kommer. Dvs. Ytelsen går nok ikke ned på en per sokkel basis, men den går ikke opp heller.

Tja, AMD påstår faktisk at ytelsen vil gå noe opp på dual-kjerne Opteron:

http://news.com.com/AMDs+dual-core+perform..._3-5397762.html

The size of the performance increase going to the new processor depends on the speed of the two chips. Comparing a computer today with one that uses two chip sockets with 90-nanometer processors, performance increases between 30 percent and 55 percent on various benchmarks, McGrath said.

På Xeon baserte systemer må en faktisk halvere antall sokler per FSB for å ikke redusere ytelsen per sokkel for slike programmer. Det er derfor Blackford og Twin Castle chipsettene med dual FSB kommer.

Jepp, det er tvingende nødvendig for at ikke Xeon MP (4+veis) skal bli fullstendig utkonkurrert av Opteron 800-serien. AMD gjorde noe lignende med sitt AMD-760MP/MPX brikkesett for Athlon MP som hadde dual FSB faktisk, men uten at det hjalp særlig på ytelsen. Neste generasjons fler-kjerne Opteron (sokkel 1207) vil nok ha flere integrerte minnekontrollere og enda raskere HyperTransport-buss tenker jeg.

 

Og ja, selvsagt kan Opteron benytte DDR400 for det er jo nettopp det jeg bruker på mitt system

Det kommer ann på hva systemet skal brukes til. SUN leverer så vidt jeg vet ikke Opteron systemer med DDR400 minne

Vel, såvidt jeg vet støtter alle dual Opteron-arbeidsstasjoner PC3200 (DDR400) minne inkludert SUN sine:

http://www.sun.com/desktop/workstation/w21...cifications.jsp

Main Memory

Up to 16 GB of PC3200 registered ECC memory with Chipkill technology operating at up to 12.8 GB/sec. bandwidth

og det er i alle fall helt uaktuelt å bruke slikt i servere. Det er heller ikke tilfeldig at Intel gikk over til DDR2-400 før de inførte 400"MHz" minne. DDR400 er ikke ansett for å være stabilt nok til servere. Det var derfor JEDEC ikke ville godkjenne det. Nå ble DDR400 likevel trumfet gjennom til bruk i desktop og AMD fant det også godt nok for arbeidsstasjoner. Det gjorde de sikkert rett i, men som sagt så er DDR400 ikke egnet til servere.

Du har nok rett i det, men det skulle ikke forundre meg at JEDEC godkjenner DDR400 til tjenere iløpet av neste år. Siden alle Opteron-prosessorer (C0-stepping og nyere) støtter slikt minne så ville det overraske meg om det ikke skjer. Likevel så tror jeg neppe 5.3GB/s minnebåndbredde per sokkel vil representere noen særlig flaskehals med tanke på ytelse iallefall.

Endret 13. desember 2004 av snorreh

[Kevlar]

Durch shaden wirt man klok...Av skade blir man klok, sier tyskerne.

Eller Durch Schaden wird man klug

[Knick Knack]

Det er heller ikke noe problem, siden minnebåndbredden ikke representerer noen flaskehals i dag.

Jeg har heller ikke sagt at det vil bli noen generell flaskehals. Det er imidlertid en del programmer som er båndbreddegbegrenset, også på dagens Opteron og Xeon systemer og de vil bare få det værre når dual core kommer. Dvs. Ytelsen går nok ikke ned på en per sokkel basis, men den går ikke opp heller.

Tja, AMD påstår faktisk at ytelsen vil gå noe opp på dual-kjerne Opteron:

http://news.com.com/AMDs+dual-core+perform..._3-5397762.html

The size of the performance increase going to the new processor depends on the speed of the two chips. Comparing a computer today with one that uses two chip sockets with 90-nanometer processors, performance increases between 30 percent and 55 percent on various benchmarks, McGrath said.

Hm interessant. Har du lest hva jeg skrev? Dette er ikke et svar på min post. Dette er god dag mann økseskaft Er litt usikker på om jeg skal forsvare en påstand eller nikke til dette.

 

Likevel så tror jeg neppe 5.3GB/s minnebåndbredde per sokkel vil representere noen særlig flaskehals med tanke på ytelse iallefall.

Tror jeg har litt problem med å forstå deg i dag. Med tanke på hva annet enn ytelse kan en hypotetisk flaskehals oppstå?

 

Om det er tvingende nødvendig å få på plass dual FSB chipset til Xeon? Tja, både ja og nei. Det kommer igjen helt an på applikasjonen. Felles FSB gir svært effektiv cache snooping og for programmer som er mer avhengig av inter-CPU kommunikasjon enn båndbredde så er dette en god modell. Med dual FSB så taper en ørlitemed tanke på cache snooping, men får mer båndbredde å spille på. Kan nok regne med at Dual FSB systemene vil gjøre det veldig bra på en del applikasjoner. F.eks har jeg sett litt på OLTP i det siste og det kan se ut til at et system med 4 Montecito prosessorer koblet via dual 667FSB vil ha litt bedre ytelse enn Power 5 og vil kunne slå 8 socket dual core Opteron (selv om en bruker Horus). Ikke pga CPU ytelsen. Den er opplagt lavere for IPF systemet, men fordi en har alt minnet samlet på en kontroller og slipper derfor skalerings problemene med distribuert minne i kombinasjon med denne typen datastruktur.

[endrebjo]

og det er i alle fall helt uaktuelt å bruke slikt i servere. Det er heller ikke tilfeldig at Intel gikk over til DDR2-400 før de inførte 400"MHz" minne. DDR400 er ikke ansett for å være stabilt nok til servere. Det var derfor JEDEC ikke ville godkjenne det. Nå ble DDR400 likevel trumfet gjennom til bruk i desktop og AMD fant det også godt nok for arbeidsstasjoner. Det gjorde de sikkert rett i, men som sagt så er DDR400 ikke egnet til servere.

Du har nok rett i det, men det skulle ikke forundre meg at JEDEC godkjenner DDR400 til tjenere iløpet av neste år. Siden alle Opteron-prosessorer (C0-stepping og nyere) støtter slikt minne så ville det forundre meg om det ikke skjer. Likevel så tror jeg neppe 5.3GB/s minnebåndbredde per sokkel vil representere noen særlig flaskehals med tanke på ytelse iallefall.

Xeon "Nocona" støtter da også DDR400-RAM.

[Knick Knack]

Xeon "Nocona" støtter da også DDR400-RAM.

Må være via i875 chipsettet i så fall. Har ikke sett noen workstation/server chipset som støtter DDR400. Kun DDR2-400 der.

[gamer73]

Jobber du hos Intel da eller, for såvidt jeg vet så kommer ikke dobbelkjerne Xeon før i 2006. Jobben din har sikkert dual-prosessor Xeon, og det er ikke det samme som dobbelkjerne siden der så befinner begge prosessor-kjernene seg på samme sokkel.

 

Ehhh ja..dual-cpu....min feil. Så det er ikek det samme nei--hehe fulgte ikke helt med jeg

[Theo343]

Men hva blir konklusjonen på flere minnekontrollere kontra en, samt type minne for generell ytelse med dobbelkjerne?? Tenker på S939/940 kontra 1206?/7.

 

Vil det ha liten effekt å oppgradere til en dobbelkjerne CPU på eks. et S939 system. Tenker da ikke bedre ytelse pr. applikasjon, men all-over.

 

Jeg er ingen programmerer eller data ingeniør, men jeg synes det er er rart man ikke kan lage et OS og et programmeringsspråk som er beregnet for å fristille programmeren fra å tenke en eller flere prosessorer og at OS'et håndterer skaleringen. Slik at man fikk OS som dynamisk tilpasset eks. CPU ressursene i maskinen også til et enkelt program som kjører, slik at OS'et ikke bare håndterer multitasking over evt. flere CPU'er.

 

Men jeg regner med at det nok høres hårreisende ut for en som vet hva dette handler om i detalj.

Endret 25. desember 2004 av Theo343

[Simen1]

Theo343:

 

Forskjellen på en og to minnekanaler på et 1-CPU system og et 2-CPU system er svært liten. Det er snakk om at AMD øker PR-ratinga med 7-9% pga den ekstra minnekanalen. (alt annet identisk). Økninga i PR-rating er nok noe overdrevet i forhold til ytelsen man får igjen. Dvs. at en to minnekanaler vil yte uder de 7-9% som PR-ratinga øker med. La oss for enkelhets skyld si 5% i gjennomsnitt. Det å plassere to CPU'er på samme sokkel vil i praksis si en reduksjon fra 2 til 1 minnekanal per CPU. Ytelsen vil synke med ca 5%. (alt annet likt)

 

Men nå er ikke alt annet helt likt. Effekten til CPU'en må senkes noe fordi det er kun en og ikke to kjølere som skal kjøle to CPU'er. Dermed må AMD gjøre et lite triks for å senke effekten. Det er motsatt av det overklokkere gjør: Senke hastigheten og spenningen noe. Trolig er det snakk om ca 0,4GHz mindre og ca 0,15V mindre. Den lavere hastigheten vil selvfølgelig senke ytelsen. Hvis jeg har rett i antagelsen om 0,4GHz så vil det si ca 15-20% redusert klokkefrekvens og rundt 15% redusert ytelse.

 

Sammenlagt så vil altså:

* 1 Socket 940 toppmodell dual CPU yte rundt 20% lavere 2 stk toppmodeller Socket 940 (gjelder all programvare)

* 1 Socket 940 toppmodell dual CPU yte rundt 80% raskere enn 1 stk toppmodell Socket 940 (kun dersom OS'et og programvaren støtter og tar fullt i bruk den ekstra ytelsen)

* 1 Socket 940 toppmodell dual CPU yte rundt 20% lavere enn 1 stk toppmodell Socket 940 (kun dersom OS'et og programvaren ikke støtter og tar fullt i bruk den ekstra ytelsen)

 

Både Windows 2000, XP, Linux og en rekke serverOS tar i bruk begge CPU'ene og forvalter CPU-kraften bra. Et program får lov til å boltre seg på en CPU. Der går grensen. Andre programmer kan få lov til å boltre seg på den andre CPU'en. OS'et kan f.eks velge at to programmer som bruker mye ytelse og samme CPU, må adskilles og flytter det ene programmet til den minst brukte CPU'en. Problemet er bare når ett program ikke er fornøyd med å boltre seg fritt på bare 1 CPU. Et program bør få kjøpre på kun 1 CPU og deles dermed ikke opp. Hvis det hadde skjedd så ville delinga og den ekstremt hyppige flyttinga av smådata mellom CPU'ene gjøre at det går mye tregere enn om alt gikk på 1 CPU. Flytting av data mellom CPU-kjerner tar ofte mange titalls om ikke 100 klokkesykluser, mens henting av data fra L1 og L2 cache tar betraktelig kortere tid. Dvs. at hvis programmet trenger noe data så vil det ta kanskje 10 ganger så lang tid å hente det fra den andre CPU'en enn om den hadde dataene selv.

[Theo343]

Siemen1:

Veldig godt forklart .

 

Skjønte også noe mer av problemstillingen i forhold til å la et program bruke flere cpu'er. Men det jeg tenkte ved å la OS'et håndtere det var mer å aktivere, men at selve støtten legges inn ved kompilering og er bygget opp noe mer i tråd med hvordan man lager et program til å utnytte flere prosessorer.

 

Ved at man som programmerer bruker en kompilator som åpner for bruken med aktivering gjennom OS. Jeg vet ikke hvilke teknikker man bruker i programmeringen for multiCPU optimalisering. Om man som programmerer statisk setter opp flere prosesser/tråder mot forskjellige CPU instanser, eller om det er programmeringsspråket eller kompileringen som åpner for dette?

 

Tanken min er at man ved å bruke en kompilator og et programeringspråk som er laget for formålet, kan legge inn en "latent" støtte flere CPU'er i alle programmer og hvor funksjonen aktiveres gjennom OS'et. Slik at man slapp å programmer spesifikt for det?

 

For slik jeg har forstått det så vil programmer som er programert spesifikt for flere CPU'er gi mye bedre ytelse enn om man hadde 1 CPU. Så tanken var å overføre programeringsteknikken inn i en kompilator slik at man gjør det enkelt for alle å lage programmer som utnytter flere CPU'er.

 

Men det jeg ikke kan noe om er hvordan man programmerer inn denne støtten???

 

Forstår du hvor jeg vil hen? selv med min sterkt begrensede innsikt.

 

Tanken er at det da ikke ville være noen stor hindring for at eks. spill produsenter kunne laget spill uten å bruke mye ekstra ressurser på å lære seg teknikker for fler-CPU programmering etc.

 

Det man ser i OS i dag er jo nesten en slags type gammeldags load-balancing basert på %bruk pr. cpu.

 

EDIT:

En eller to minnekanaler.. tenker du da single eller dual channel minnebruk slik som man hadde allerede i Nforce2? Det jeg mente var mer det at man har 1 eller flere minnekontrollere slik snorreh beskriver. Det ugjør vel i flere tilfeller opptill mange flere minnekanaler?

Endret 25. desember 2004 av Theo343

[Simen1]

Jeg tror jeg skjønne ja. Støtten for flere CPU'er kommer inn når man spesifikt programmerer "2 programmer" som gjør hver sine ting for ett program. Oppgavene som er adskilt bør være minst mulig koblet til hverandre for å være effektive. Dvs. en løkke som gjør to operasjoner der det ene resultatet avhenger av det andre bør ikke deles inn i to tråder/programmer. (samme begrunnelse som i posten over)

 

Derimot kan to delprogrammer som gjør ganske uavhengige ting plasseres i hver sin tråd. Da kan hver tråd 99% av tiden jobbe mot data som finnes i L1 eller L2 cachen på samme CPU (svært raskt), i stedet for å vente på forsinkelsen det tar å hente data fra den andre CPU'en. Doom3 har gjort en lur ting: De har delt opp lyd i en tråd, og grafikk i en tråd. Disse to tingene henger ikke så voldsomt tett sammen at de fint kan tåle en ganske lang ventetid for oppdaterte data. Doom3 sender lyd-tråden til den ene CPU'en mens grafikktråden sendes til den andre.

 

I tilfellet med doom3 så bruker grafikktråden langt mer CPU-kraft enn lyd-tråden. For eksemplets skyld la oss si 100% av CPU-kraften på den ene CPU'en brukes til grafikk og 20% av den andre til lyd. Hvis begge måtte kjøre på en CPU så ville grafikktråden blitt redusert til 80% av den ene CPU'en mens lyden fikk sine 20%. Grafikkdelen vil altså gå 20% tregere på 1 CPU enn på 2. Ytelseøkningen av å bruke 2 CPU'er er altså ikke så voldsom.

 

Det er ikke lett for programmereren å dele opp programmet i deler som krever like mye ytelse og er logisk sett lite koblet sammen. Programmereren vet skjelden før det ferdige produktet hvor mye ytelse hver del av programmet tar og hvor tett koblet de forskjellige delene blir. I tillegg gir forskjellige CPU'er ulik ytelse på de ulike delene.

 

Kort sagt kan vi si at 2 CPU'er kan inntil doble ytelsen i forhold til 1 CPU i helt spesielle tilfeller, men vil normalt yte en plass mellom 1 og 2 CPU'er. Hvis programvaren er dårlig skrevet så kan til og med ytelsen synke og det betraktelig. Om programmereren oppdager dette så slår han heller bare sammen delprogrammene og kjører de alle i en tråd.

[Theo343]

Simen1:

Hmm begynner å forstå nå ja.

 

Vil det si at rendering og encoding program(som vel er en mer forutsigbar og lineær oppgave) som utnytter multi CPU kraft evt. deler opp oppgaven i flere separate deloppgaver og fordeler disse over flere CPU'er. Og når alle resultatene er ferdige så settes de sammen?

 

Litt som å ha en lastebil med 1 lass poteter som skal skrelles hvor man deler massen på 2, gir det til 2 skrellere som kaster de ferdige bitene i samme bøtte. Hvor alt settes sammen når alt er ferdig. Men hva når det skjer i realtime?

 

Var lurt dette med å dele grafikk og musikk. Man kan vel dele det opp ennå mer. Eks. at AI skilles ut, men det er jo avhengig av forsinkelsene man får ved å dele opp. Grafikk på en CPU, AI og lyd på den andre.

 

Kan sikkert finne flere elementer, men det er avhenger av om de egner seg å dele opp.

 

Men dvs. at hvis jeg spiller Doom3 på en maskin med SoundStorm og 2 CPU'er så utnytter jeg kun en CPU, men alikevel 2 prosessorer, siden APU'en håndterer lyden? Men dette skjer jo automatisk uten spesiell støtte for APU? Mulig jeg roter meg veldig bort her nå..

Endret 25. desember 2004 av Theo343

[Simen1]

Det stemmer bra

 

Oppgaver som er svært like og kan gjøres parallellt (ganske uavhengig av hverandre) egner seg godt for å bli delt opp i flere tråder. Det er mye rendering, filtere, simulering av mekaniske og fysiske systemer som kan deles opp effektivt. Serverbruk med ørten brukere kan også deles ganske enkelt. Nå snakker jeg om 1-4 CPU'er og ikke så mye mer enn det. Da begynner det å bli fler ting som spiller inn, bla. brikkesett, horus-brikker, og konfigurasjon av clustere, minnesystem osv. (Dette er noe brukeren Knick Knack kan mye om)

 

Det er riktig det med soundstorm også. CPU'en som driver grafikken bruker samme kraft, men den som driver lyden blir kanskje avlastet fra 20% til 2%. Eller hvis man bruker 1 CPU: Da avlastes lyden fra 20 til 2% og frigir ytelse så grafikkdelen kan øke fra 80 til 98%.

[Theo343]

Takker. Skal se sjekke litt og se om jeg finner flere tråder rundt dette. En ting jeg tenkte på er eks. database servere som har mange instanser, sessions etc. Vet at eks. Oracle har støtte for og utnytter både HyperThreading(HT), MultiCPU og serverclustering. Mye av den samme saken, men alikevel så enormt forskjellig.

 

Et eksempel på at det å dele opp oppgaver kan gi bedre ytelse er VMWARE sin ESX Server - virtual smp/multi-cpu teknikk som kanskje emulerer HT i noe grad og er helt software basert.

Der blir programmer som støtter flere CPU'er faktisk vesentlig raskere ferdig, selv om man bare har 1 CPU i maskinen. Selv når CPU'en bruker HT.

Endret 25. desember 2004 av Theo343

[endrebjo]

Xeon "Nocona" støtter da også DDR400-RAM.

Må være via i875 chipsettet i så fall. Har ikke sett noen workstation/server chipset som støtter DDR400. Kun DDR2-400 der.

Jeg glemte selvfølgelig at 800MHz FSB-brikkesettene til Xeon (E7525, E7520 og E7320) benytter seg av DDR2

[snorreh]

X-bit labs har en glimrende artikkel om dobbelkjerne og fremtiden:

 

One Core Is Good. Two Cores Are Even Better!

 

Anbefalt lesing!

[Simen1]

Ikke for å disse intel, men det var en ganske opsiktsvekkende plansje der:

 

 

Til nå har bare single-core vært gjeldende for desktop-markedet og ytelsen har steget jevnt (logaritmisk) siden "tidenes morgen". Ofte feilaktig kalt "moores lov". Plansjen viser at single-core ytelse ikke vil fortsette denne trenden men vil flate kraftig ut og bli linær i stedet for logaritmisk. Fra nå av ser det ut til at man må ty til flertrådet ytelse for å kunne fortsette trenden. Det triste er at en god del programvare rett og slett ikke kan gjøres flertrådet og vil derfor følge den lineære kurven i stedet for den logaritmiske. Jeg tipper at det første som vil skje er at programvarebransjen henger seg på multitråd i full fart og at det tar noen år før de oppdager at dette sporet ikke kan utnyttes mer. Da vil nok IA64 være eneste vei ut av ytelse-hullet. Men det er sikkert mange år til.

 

Bare for å ha sagt det: Det blir neppe noe bedre for AMD sin del på lang sikt.