TEST: Intel Core 2 Extreme QX6700

[ull2000]

Hvorfor er ingen AMD X2 prosessorer med i sammenligningen?

Duger de ikke til noe?

Kan hende det sto i testen men at jeg bare overså det.. =)

7209028[/snapback]

 

FX-62 er strengt tatt en X2, da.

Endret 3. november 2006 av ull2000

[jon67]

Det hele handler om at intel haler ut tida for å servere nye og bedre produkter med små forbedringer for hver gang med korte mellomrom. Altså melke kundene for penger. Hvis de hadde samlet opp flere nyheter som f.eks quad-kjerne 1333FSB, støtte for DDR2-1066, PCI express v2.0 osv i en og samme pakke så ville kundene oppgradert skjeldnere og intel ville tjent mindre. Det er altså bare taktikkeri fra intels side.

7208386[/snapback]

 

Hvorfor tror du at hovedtyngden av markedet oppgraderer for hver minste lille forbedring som kommer? De fleste større bedriftskunders oppgraderingsplaner er basert på avskrivninger og ikke teknologi, og særlig PCer brukes gjerne til de ikke orker mer. Dette gjelder også for de fleste privatkunder, de fleste bruker PCen med det OSet som ble levert med, helt til systemet er dårligere enn gjeldende low-end. Kun et fåtall entusiaster oppgraderer regelmessig ved arkitektur/sokkelskifter.

[Scortech]

Mener du at spill må programeres anerledes for denne CPU-typen?

At man bruker andre programeringspråk/kompilator eller lignende for å få dette til?

 

Ja det må de...Akkurat som amd 64 cpuer og til X2 CPU..også nå til quad core..Jeg synes så synd på spill programmerere..stakkars folk..det blir ikke akkurat lettere og lettere for de....

Endret 3. november 2006 av Scortech

[lohelle]

Mener du at spill må programeres anerledes for denne CPU-typen?

At man bruker andre programeringspråk/kompilator eller lignende for å få dette til?

 

Ja det må de...Akkurat som amd 64 cpuer og til X2 CPU..også nå til quad core..Jeg synes så synd på spill programmerere..stakkars folk..det blir ikke akkurat lettere og lettere for de....

7210174[/snapback]

 

det er vel strengt tatt ikke vanskeligere å programmere spill for 4 kjerner enn for 2 kjerner.. Det handler om å multithread'e.. Men det er MYE vanskeligere å multithread'e (programmere) i spill enn i for eks rendering av tegninger osv fordi man er mye mer avhengig av at alt skjer til rett tid.. Ved multithreading i spill så må (har jeg hørt) man i større grad vente til en thread er ferdig før den neste kan begynne pga at bruker påvirker resultatet (handlingen) etter hvert..

Vel.. noe i den retningen. Andre er sikkert MYE flinkere til å forklare enn meg.

Endret 3. november 2006 av lohelle

[Scortech]

Men det er MYE vanskeligere å multithread'e (programmere) i spill enn i for eks rendering av tegninger osv fordi man er mye mer avhengig av at alt skjer til rett tid

 

Akkurat..men tror ikke det er noe særlig vanskeligere men at det tar mye lengre tid å få gjort det..

[Del]

det er vel strengt tatt ikke vanskeligere å programmere spill for 4 kjerner enn for 2 kjerner..

I utgangspunktet ja, men i praksis vil det vise seg å være lettere å utnytte to kjerner, rett og slett fordi du får utnyttet det trivielle parallelliseringsnivået med to. La meg illustrere med et enkelt eksempel: når du spiller er gjerne spillet en egen tråd men diverse andre prosesser kjører samtidig (anitvirus, emule, diverse OS prosesser, whatever). Her vil spillet dominere CPU bruk totalt, slik at selv om en kjerne dedikeres til spillet kan den andre kjernen fint klare alt det andre til sammen. Skal du få noe som helst ut av fire kjerner er dette vesentlig værre.

 

Det handler om å multithread'e.. Men det er MYE vanskeligere å multithread'e (programmere) i spill enn i for eks rendering av tegninger osv fordi man er mye mer avhengig av at alt skjer til rett tid.. Ved multithreading i spill så må (har jeg hørt) man i større grad vente til en thread er ferdig før den neste kan begynne pga at bruker påvirker resultatet (handlingen) etter hvert..

Vel.. noe i den retningen. Andre er sikkert MYE flinkere til å forklare enn meg.

7210224[/snapback]

Jeg er ingen spillprogrammere, men dette problemet har opptatt meg en del. Såvidt jeg kan skjønne burde det ikke være vanskeligere å parallellisere for spill enn det er for andre oppgaver. Problemer knyttet til synkronisering tror jeg hovedsaklig er problemer knyttet til oppgaver som i utgangspunktet ikke er egnet for parallellisering. F.eks. dine bevegelser av musa/tastatur når du spiller er typisk real-time, og har derfor en sekvensiell natur. Grafikk har vi allerede sett parallellisert med stort hell, nemlig i form av skjermkort (hvilket fortsatt utgjør den mest prosesseringshungrige delen av spill). Eksistensen av Ageias PhysX forteller oss at fysikk i spill også kan parallelliseres massivt. AI burde også kunne dra meget god nytte av parallellisering. Jeg er overbevist om at vi vil få se godt parallelliserte spill, men det kan ta tid, og noen må se så stort markedspotensiale for å lage et slikt spill (eller kanskje mer sannsynlig spillmotor) at det bærer seg økonomisk. Det er nemlig ingen tvil om at parallellisering av kode pr. i dag krever betydelig innsats.

Endret 3. november 2006 av Del

[Simen1]

ah ok som den typiske ingeniøren jeg er så leste jeg selvfølgelig ikke forklaringen Vel da er den jo strengt tatt riktig, men en kunne jo invertert formelen for de grå feltene og slik fårr alt på samme malen uansett.

7207232[/snapback]

Formlene i de grå feltene er inverterte. Jeg har dobbeltsjekket formlene nå og laget bakgrunnsfarge med forklaring over det hele nå. Tror dette skal stemme ganske bra.

 

https://www.diskusjon.no/uploads/post-3851-1162570262.png

[lohelle]

hvor stor er en "thread" egentlig? dvs, hvor mange threads trengs for å rendre en frame i for eks quake4 med de spillere og "monstere" som måtte være der.. Vet at dette vil variere voldsomt, men snakker vi 1, 2, 10, 50, 100, 1000?

 

om det er et HØYT tall så burde det vel strengt tatt være mye lettere enn om det er 1-5 for eks.. om det er et så lavt tall så vil jeg tro at dette med synkronisering og input vil ha mer å si for "vanskeligheten" mtp implementering av skikkelig multithreading i forhold til om det er hundevis av threads pr frame... hmm.. ja, noe i den duren...

 

er ikke helt stø på dette, men den som "vil" skjønner nok hva jeg mener.

Endret 3. november 2006 av lohelle

[Del]

hvor stor er en "thread" egentlig? dvs, hvor mange threads trengs for å rendre en frame i for eks quake4 med de spillere og "monstere" som måtte være der.. Vet at dette vil variere voldsomt, men snakker vi 1, 2, 10, 50, 100, 1000?

Så stor du vil. En. Sjekk wikipedia for definisjon av process og thread. Det du kanskje mener er hvor mange det kan være fordelaktige å dele dem inn i dersom man har flust av kjerner.

om det er et HØYT tall så burde det vel strengt tatt være mye lettere enn om det er 1-5 for eks.. om det er et så lavt tall så vil jeg tro at dette med synkronisering og input vil ha mer å si for "vanskeligheten" mtp implementering av skikkelig multithreading i forhold til om det er hundevis av threads pr frame... hmm.. ja, noe i den duren...

 

er ikke helt stø på dette, men den som "vil" skjønner nok hva jeg mener.

7211763[/snapback]

Skal prøve. Det er veldig viktig å bestemme seg for hva man skal parallellisere, når man ønsker å distribuere en oppgave mellom CPU'er. Her vil jeg si at en generell regel er at du typisk ønsker å parallellisere data, ikke oppgaver, en av grunnene er at du da normalt vil ha en strategi som skalerer med antall CPU'er. La meg prøve et eksempel, i SLI/Crossfire bør du heller fordele skjermen bokstavelig talt mellom GPU'ene enn å fordele hvilke objekter de skal tegne. Der har ATI såvidt jeg husker lagt seg på et rutemønster, dette kan utvides ved økt antall GPU'er, bare ved å øke oppløsningen på rutenettet, mens antall objekter vil variere veldig, og ofte være både begrenset antall, og lite balansert i prosesseringsbehov. Det er derimot veldig fristende å se for seg parallellisering ved å dele oppgaver i prosesser (AI, fysikk, lyd, osv.), siden dette kan være lavt hengende frukt, men med bitter ettersmak.

 

Jeg kjenner ikke til hva som er blitt gjort i Quake 4.

[Anders Jensen]

Spill er vanskelige å parallelisere fordi de faller inn under gruppen kjent som sanntids programmer eller real time som de kaller det på nynorsk. Du får altså inn en ekstra dimmensjon, nemlig tid, som er med på å bryte parallelliteten noe. I tillegg må en i real time systemer ha mer prosesseringskraft enn hva en som regel trenger fordi det må planlegges for worst case scenario, men dette har ingenting med selve parallelliseringsproblematikken å gjøre.

 

Heldig vis blir realtime systemer stadig enklere å håndtere fordi mennesker er like trege i dag som vi var for 20 år siden, men maskinene raser videre og vil fortsette med det. Det er imidlertid ikke alle real time systemer som forholder seg til mennesker og de kan ha andre krav til responstid.

 

Hvis kravet til responstid er veldig slapt i forhold til maskin hastigheten vil forskjellen mellom å parallellisere real time og andre programmer viskes ut. En kan jo si at alle programmer er real time, bare at noen har veldig lavt krav til responstid.

[Gjest Slettet+6132]

Når det gjelder effektforbruket quad-core kontra dual-core, har xs.org's "Coolaler" gjort denne fine testen.

Quad-core "sluker" en god del mer strøm enn dual-core.. omtrent like "ille" som en overvolted og skamklokket "Smithfield".

Endret 3. november 2006 av Slettet+6132

[Kjetil Lura]

Stusset også litt over dette effektforbruke, hos anand så måler de quaden til å bruke vesentlig mer effekt.

 

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2866&p=5

 

AtW

7206133[/snapback]

Om ikke eg husker feil er det hele maskine de måler, ikke bare prosessoren. Eller tar eg feil?

QX6700 skal bruke ca 130W 100% load, mens E6700 skal bruke ca 65W 100% load.

Er eg på bær tur nå folkens

[ATWindsor]

Stusset også litt over dette effektforbruke, hos anand så måler de quaden til å bruke vesentlig mer effekt.

 

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2866&p=5

 

AtW

7206133[/snapback]

Om ikke eg husker feil er det hele maskine de måler, ikke bare prosessoren. Eller tar eg feil?

QX6700 skal bruke ca 130W 100% load, mens E6700 skal bruke ca 65W 100% load.

Er eg på bær tur nå folkens

7213932[/snapback]

 

Ja, de måler hele maskina, men det har de gjort i hw.no sin test også, og i hw-no-testen er forskjellene langt mindre.

 

AtW

[Kjetil Lura]

Har de brukt like hardware i oppsetene på test maskinene? Kan være det som er forskjellen i den økte strømbruken.

PS: Har ikke lest begge, holder på å setter opp 2 E6700 maskiner. Har ikke tid å lese begge. Tar det kanskje senere.

[ATWindsor]

Har de brukt like hardware i oppsetene på test maskinene? Kan være det som er forskjellen i den økte strømbruken.

PS: Har ikke lest begge, holder på å setter opp 2 E6700 maskiner. Har ikke tid å lese begge. Tar det kanskje senere.

7214525[/snapback]

 

De har ikke brukt den samme nei, også anand gjør i mine øyne en tabbe, da de prøver å regne ut "performance per watt" på denne kontra andre CPUer, da de regner med hele systemet, noe som sikkert kan forsvares, men når de har kraftige skjermkort i maskina blir CPUens relative forbruk mye mindre, slik at man tjener uforholdsmessig mye "performance per watt" på å ha en kjappere CPU, selv om den bruker vesentlig mer effekt.

 

Og selv om hardwaren ikke er den samme, så bør forskjellen (den absolutte) i watt være omtrent på samme nivå. (effektiviteten til PSU har litt å si, men det er ikke så stor forskjell på dette)

 

AtW

[Del]

Spill er vanskelige å parallelisere fordi de faller inn under gruppen kjent som sanntids programmer eller real time som de kaller det på nynorsk. Du får altså inn en ekstra dimmensjon, nemlig tid, som er med på å bryte parallelliteten noe. I tillegg må en i real time systemer ha mer prosesseringskraft enn hva en som regel trenger fordi det må planlegges for worst case scenario, men dette har ingenting med selve parallelliseringsproblematikken å gjøre.

7213769[/snapback]

Så da er det vel naturlig å spørre seg om worst case scenario vil endre seg betydelig ved parallellisering, det er vel nettopp dette jeg sikter til at ikke er så stort problem som mange vil ha det til.

[Anders Jensen]

Spill er vanskelige å parallelisere fordi de faller inn under gruppen kjent som sanntids programmer eller real time som de kaller det på nynorsk. Du får altså inn en ekstra dimmensjon, nemlig tid, som er med på å bryte parallelliteten noe. I tillegg må en i real time systemer ha mer prosesseringskraft enn hva en som regel trenger fordi det må planlegges for worst case scenario, men dette har ingenting med selve parallelliseringsproblematikken å gjøre.

7213769[/snapback]

Så da er det vel naturlig å spørre seg om worst case scenario vil endre seg betydelig ved parallellisering, det er vel nettopp dette jeg sikter til at ikke er så stort problem som mange vil ha det til.

7215085[/snapback]

Nei altså med planlegging av worst case i denne sammenheng så betyr jo det bare at maskina må ha kalkulasjonene klargjort innen ev viss tidsfrist uansett omstendighet. Akkurat det blir jo enklere ved parallelisering, men en bryter opp oppgavene i tidsintervall, noe som bryter parallelliteten noe. Det verste er antagelig synkronisering, fordi en må gjøre det oftere i en real time applikasjon enn i andre applikasjoner. Det gjør jo at mengden serialisert overhead vokser og dermed blir paralleliseringen vanskeligere.

 

Ved f.eks rendering så kan en kjerne få tildelt en oppgave den kan kose seg med i ro og mak i flere minutter eller timer uten noen som helst interaksjon med resten av applikasjonen og med minimal OS interaksjon. I realtime applikasjoner, som f.eks. et spill, vil tidsintervallet helst ligge på mindre enn 1/60 sekunder. Da blir det mye mer overhead fordi informasjon skal deles hele tiden.

[Del]

Det gjør jo at mengden serialisert overhead vokser og dermed blir paralleliseringen vanskeligere.

Dette er jo et viktig poeng, og i hvor stor grad dette er et problem varierer sikkert fra spill til spill. Jeg er som sagt ingen spillprogrammerer, så jeg vet ikke hvor den CPU intensive biten av koden er, og i hvor stor grad den er seriell i natur.

 

Ved f.eks rendering så kan en kjerne få tildelt en oppgave den kan kose seg med i ro og mak i flere minutter eller timer uten noen som helst interaksjon med resten av applikasjonen og med minimal OS interaksjon. I realtime applikasjoner, som f.eks. et spill, vil tidsintervallet helst ligge på mindre enn 1/60 sekunder. Da blir det mye mer overhead fordi informasjon skal deles hele tiden.

7215663[/snapback]

Jeg tror dette bare betyr at man må være ekstra varsom med parallelliseringsstrategi, og i utgangspunktet velge den så ortogonal som mulig med tidsaksen til spillet for å unngå synkroniseringsproblematikk. Tenk heller helt banalt på problemet: Ved et gitt tidspunkt i et spill er det behov for å gjøre en regneoperasjon som er så CPU intensiv at den på et gitt system utgjør flaskehalsen på det tidspunktet (m.a.o. hvis man kunne unngått eller gjort regneoperasjonen raskere ville man fått høyere fps akkurat da). Denne regneoperasjon kan sannsynligvis (min påstand) parallelliseres greit til fire CPU'er på en shared memory sak, og vil da kunne gå vesentlig fortere. Regneoperasjonen er ferdig når den er ferdig, og først da kan resultatet påvirke spillet. På denne måten burde det gå an å løskoble synkroniseringen med tid i spillet med synkroniseringen i trådene man parallelliserer. Dette blir jo gjort meget effektivt på ILP nivå.

 

Artikkelen til Mark Smotherman så veldig interessant ut, skal lese den når jeg får tid. Du mener vel Ta og ikke At?

[sveinsel]

Er ikke helt fornøgd med forklaringene hvordan belaste alle fire kjernene likt. Jeg trodde kanskje det er Windows (oprativsystemet) sin oppgave ...

Programerere for vanlige applikasjonehar vel ikke verktøy for det?

[Del]

Er ikke helt fornøgd med forklaringene hvordan belaste alle fire kjernene likt. Jeg trodde  kanskje det er Windows (oprativsystemet) sin oppgave ...

Programerere for vanlige applikasjonehar vel ikke verktøy for det?

7223518[/snapback]

OS kan ikke dele en prosess inn i flere prosesser like lite som det kan dele en tråd i flere tråder, det må programmerer gjøre. Programmereren skal da helst gjøre dette slik at arbeidsmengden på hver tråd eller prosess blir like stor. Programmerere har mange verktøy for å gjøre dette, blant annet kompilator.