Slik får du mest ut av Skyrim på maskinen din

[Gjest Slettet+6132]

Er en ting jeg har lurt på, som hadde vært greit om noen kunne forklare for meg.. CPU'ene får jo stadig flere cores / threads. Multicore-programmering er en god del vanskeligere enn mot single core. Er det umulig for f.eks Intel å lage en Quad core som oppererer som en single core? Altså med en slags kontroll som automatisk assigner tasks til forskjellige threads så ting blir utført i riktig rekkefølge. Den måtte også inneholdt ett slags nummereringsystem som passet på at kallene ble gjort i riktig rekkefølge over de forskjellige kjernene.

 

Det vanlige problemet er jo at flere kjerner ikke kommuniserer så om man bare lar dem løpe fritt på å utføre noe som dette:

 

int a = 1;

int b = 2;

int c = a + b;

 

Så kan kjernen som får int c = a + b kjøre før f.eks int b = 2; og da blir det problemer. Men med et slags nummereringsystem som passer på dette burde det vel gå.

 

Vi kommer jo sikkert snart til å sitte på cpu'er med 8 eller flere kjerner, så dette er imao noe som bør tenkes på om det ikke allerede er noen som gjøre det.

 

Hadde jo vært praktisk å kunne utnytte alle kjerner til en hver tid.

 

Nå har ikke jeg veldig mye peiling da..

Endret 14. desember 2011 av Slettet+6132

[N o r e n g]

Klarer du å få en flerkjerneprosessor til å "smelte sammen" kjerner for en oppgave vil du bli styrtrik. Dette har aldri blitt gjort og det man gjør i dag er heller å delegere oppgaver til andre kjerner, etterhvert som programmeringsspråkene blir mer tilpasset blir dette bedre og bedre, men det er fortsatt ekstremt vanskelig.

 

For eksemplet ditt er nok dette nærmere hvordan det foregår i prosessoren

sett reg1 til 1

sett reg2 til 2

Hent reg1 til data

Hent reg2 til instruksjon

Summer data + instruksjon

Lagre til reg3

 

Det er ganske vanskelig å dele over flere tråder

[efikkan]

bun9box:

Det var et dårlig eksempel, siden kompilatoren vil optimalisere det til int c = 3;

Hvis ikke måtte uansett kjerne nummer 2 skrevet b tilbake slik at kjerne nummer 1 kunne lest den til registeret før add-instruksjonen kunne utføres, å lese det direkte fra ram blir for tregt. Konklusjonen er uansett at du oppnår ingenting med denne typen situasjoner. I tillegg til dette kommer den heftige overheaden til selve kernel i operativsystemet, som må utføre en rekke instruksjoner for å styre threads.

 

Når du trenger synkronisering så er det en stor oppgave å utnytte mange kjerner optimalt, flere er verre enn få. PCer har typisk et hundretalls med threads kjørende i bakgrunnen i tillegg, som gjør overheaden ennå større. Multithreading er fint så lenge du trenger minimalt med synkronisering, og kan gjøre separate arbeidsoppgaver, f.eks. én thread til rendering og én til IO. For noen år siden kom DirectX 10 med støtte for multithreading, og mange trodde at nå vil CPUen utnyttes 100%, men det er tydelig at de ikke forstår hva det dreier seg om. Driveren kjører fremdeles som én thread, men flere threads kan kommunisere med den (dog ikke samtidig). OpenGL har det samme, der flere threads kan dele et context, eller det kan opprettes flere context. Dette gir ikke bedre særlig ytelse, men hensikten er heller at én thread kan gjøre rendering og én kan laste inn ting til skjermkortet, og så ligger de og veksler på hvilken som har tilgang til driveren. Et scenario for å forklare prinsippet:

Dette er et konstruert eksempel: Renderingthread rendrer enkel scene, bruker 90% av tiden til driveren.

Loadingthread trenger en del tid på å laste fra disk og forberede strukturer og teksturer i bufre til skjermkortet. Siden den bør okkupere tilgangen til skjermkortet minst mulig (overføring tar mye tid!), bruker den da kun tiden den kommuniserer med driveren til å overføre data, mens venting på disk, kalkuleringer osv. gjøres de resterende 90% av tiden. Men i task manager vil det se ut som den ene kjernen utnyttes 90+% og den andre rundt 30-40% (effektivt), i en del tilfeller vil det stå 100% på begge hvis det ikke er en liten sleep() i hver sykel. Summert over to kjerner får du da rundt 60-65% utnyttelse av CPU, som høres dårlig ut.

Alternativet til dette er å gjøre alt dette i én thread, som vil gi noe mer forsinkelser.

Rent teknisk ser jeg ikke for meg hvordan det skulle blitt mulig med f.eks. 8 threads som hver sendte sine kall til driveren samtidig under samme rendering. Kallene som blir gitt er tross alt kall som skal utføres sekvensielt (i henhold til gangen i rendering pipeline), så det ville blitt vanskelig å få disse til å samarbeide. Når det gjelder selve renderingen på GPU så styres det internt hvordan regneoppgavene fordeles på x SIMD-grupper (GPUen har en egen styringsprosessor), multithreading på CPU vil ikke hjelpe noe her.

 

For de fleste spill i dag er ikke CPU noen begrensning slik de er implementert nå, men CPUen er en begrensning i form av at den hindrer utviklerne i å lage mer dynamiske verdener. Men dette problemet vil på sett og vis løses ganske snart siden Kepler vil la GPU hente data direkte fra systemminnet uten trege kall til driveren. Da kan renderingthread bare enkelt og greit spesifisere hvilke bufre som skal rendres med hvilke shader-programmer, så kan en OpenCL-kernel på GPUen bytte ut de underliggende data, og hvis mengden bufre er rimelig konstant kan til og med hele greiene puttes i en displaylist som reduserer kallene til driveren til 1. Dette muliggjør avanserte LoD-algoritmer implementert på GPU.

 

Dette ble litt teknisk men ikke i dybden, har dessverre ikke så mye tid til å forklare alt i dag.

[RRhoads]

Joa, jeg ser den. Men CPU blir fortsatt en flaskehals pga at hele ikke blir brukt. Samme med minne egentlig.

 

Joda, jeg ser greia med konsoller.

Crysis kjører bare på to tråder, det er ikke lett å få til en CPU-flaskehals der. Minne er det viktigst å ha nok av, alt som er mer enn nok er ubrukelig.

Ja, men spillet bruker jo hele av det den har tilgjengelig, altså 25%.

Du hadde nok fått mer ut av en CPU med ferre kjerner og mer ytelse per kjerne. God flertrådet programmering i realtime systemer som spill er veldig utfordrende og vil nok aldri bli i stand til å utnytte den fulle bredden i high-end prosessorer.

Sant nok det, og jeg skjønner det. Husker ikke hvilket spill jeg spilte som kunne bruke hele CPU'n. Mulig det var F1 2010?

[RRhoads]

La oss ty til Wikipedia: "A bottleneck is a phenomenon where the performance or capacity of an entire system is limited by a single or limited number of components or resources. The term bottleneck is taken from the 'assets are water' metaphor. As water is poured out of a bottle, the rate of outflow is limited by the width of the conduit of exit—that is, bottleneck."

Konklusjonen må være, har du mer minne eller flere prosessorer enn du trenger og disse ikke blir utnyttet så ligger flaskehalsen et annet sted. Ta f.eks. to like spillmaskiner, den ene med 2 GB RAM, og den andre med 64 GB RAM, spillytelsen er tilnærmet den samme, da ligger flaskehalsen et annet sted, som regel skjermkortet. At et spill ikke utnytter 100% på alle ressurser kan ikke betegnes som dårlig programmering, strengt tatt bør det brukes minst mulig.

 

og fremdeles lurer jeg på hvordan flere threads skal gi bedre grafikk... (teknisk forklaring)

 

Jeg ser at flere her påstår de har full ytelse på langt svakere CPUer enn noen av dere, mest sannsynlig skyldes dette bugs i driver. Multithreading har ingenting med saken å gjøre, det har ingen hensikt for rendering. Ytelsen til en enkeltkjerne kan ha betydning, men det er utelukket i dette tilfelle når enkelte hevder en langt svakere Phenom klarer det fint og høyt klokkede i7 skal ha problemer.

 

Jeg er uenig med deg her. CPU'n ligger på 25%, og spillet bruker 100% av det som er fysisk mulig. Hvis spillet kunne brukt 50% av CPU, ville ytelsen gått opp. Akkurat dette med å programmere spill til å bruke flere tråder, skjønner jeg kan være vanskelig, og det er ikke alltid det vil ha noe å si. I dette spillet kun det tatt seg av f.eks fysikken.

 

Det samme med minne. Spillet kan kun bruke 2GB minne, men man kan bruke en uoffisiell mod som gjør at spillet støtter 4GB. Alle sier ytelsen går opp. Dette her er jo ikke vanskelig for en spillutvikler å programmere inn, da det har kommet en uoffisiell mod.

 

Det er og mulig at folk med dårligere hardware kjører spillet i DX9 eller rett og slett lyver for alt jeg vet. Det er og mulig at de synes fps'n er glatt nok, selv om den bikker under 30fps nå og da.

[efikkan]

Hvis spillet kunne brukt 50% av CPU, ville ytelsen gått opp.

Dette her må du begrunne teknisk.

 

Det samme med minne. Spillet kan kun bruke 2GB minne, men man kan bruke en uoffisiell mod som gjør at spillet støtter 4GB. Alle sier ytelsen går opp. Dette her er jo ikke vanskelig for en spillutvikler å programmere inn, da det har kommet en uoffisiell mod.

Det høres ut som en bug som har blitt fikset. Det blir helt feil å anta at vi da kan gjøre tilsvarende og få bedre ytelse av 8 GB, 16 GB osv. Du kan rett og slett ikke generalisere dett.

 

Det er og mulig at folk med dårligere hardware kjører spillet i DX9 eller rett og slett lyver for alt jeg vet. Det er og mulig at de synes fps'n er glatt nok, selv om den bikker under 30fps nå og da.

Verken du eller jeg vet om folk her lyver om tallene sine. Det er uansett en god idé å oppgi driverversjon og versjon av spillet.

[RRhoads]

Hvis spillet kunne brukt 50% av CPU, ville ytelsen gått opp.

Dette her må du begrunne teknisk.

 

Du kan heller begrunne hvorfor et spill som bruker 100% av CPU-ressursene spillet er programmert til å bruke ikke vil yte bedre med mer CPU-ressurser.

 

 

Du skriver over her:

"At et spill ikke utnytter 100% på alle ressurser kan ikke betegnes som dårlig programmering, strengt tatt bør det brukes minst mulig."

Det virker som du misforstår litt her. Det er motsatt. Spillet bruker konstant 100% av det som er tilgjengelig, hele tiden.

8 tråder=100%

2 tråder=25%

Spillet bruker begge trådene maksimalt hele tiden, altså 25% Hadde spillet kun brukt 20%, ville jeg skjønt at det ikke ville hjulpet med flere tråder, men det er ikke tilfellet her.

 

Det samme med minne. Spillet kan kun bruke 2GB minne, men man kan bruke en uoffisiell mod som gjør at spillet støtter 4GB. Alle sier ytelsen går opp. Dette her er jo ikke vanskelig for en spillutvikler å programmere inn, da det har kommet en uoffisiell mod.

Det høres ut som en bug som har blitt fikset. Det blir helt feil å anta at vi da kan gjøre tilsvarende og få bedre ytelse av 8 GB, 16 GB osv. Du kan rett og slett ikke generalisere dett.

Har ikke nevnt 8GB og 16GB, jeg, så deg om det. Det er ikke kommet noen offisiell patch som fikser det. Det er en MOD som fikser det.

 

 

Det er og mulig at folk med dårligere hardware kjører spillet i DX9 eller rett og slett lyver for alt jeg vet. Det er og mulig at de synes fps'n er glatt nok, selv om den bikker under 30fps nå og da.

Verken du eller jeg vet om folk her lyver om tallene sine. Det er uansett en god idé å oppgi driverversjon og versjon av spillet.

Selv kjører jeg med nest nyeste AMD driver, 10.11a. Kjører Windows 7 64bit. Siste patch installert. Ingen mods(nei, ikke engang den uoffisielle 4GB moden)

[efikkan]

At en thread belaster en kjerne tilsynelatende 100% betyr absolutt ikke at en raskere CPU vil gi bedre ytelse. Det er ganske vanlig (som nevnt over) at threads som vil ha maksimal ytelse ikke bruker sleep, dermed vil de konstant bruke all tilgjengelig CPU-kraft selv om det egentlig ikke trengs (går i en uendelig løkke). Det er ganske vanlig at 2 threads gjør dette, den første er til IO-events (mus, tastatur osv.) og den andre til rendering. F.eks. mine egne prosjekter gjør også akkurat dette, som er ganske viktig på X.org siden den lager noe hinsides med events ved musebevegelser, hvis jeg skal ha en sleep der kan det skape forsinkelser (på musen altså), derfor er det vanlig å polle for events konstant. Tilsvarende vil en rendering-thread ligge konstant og mase på om driveren er ferdig.

[RRhoads]

At en thread belaster en kjerne tilsynelatende 100% betyr absolutt ikke at en raskere CPU vil gi bedre ytelse. Det er ganske vanlig (som nevnt over) at threads som vil ha maksimal ytelse ikke bruker sleep, dermed vil de konstant bruke all tilgjengelig CPU-kraft selv om det egentlig ikke trengs (går i en uendelig løkke). Det er ganske vanlig at 2 threads gjør dette, den første er til IO-events (mus, tastatur osv.) og den andre til rendering. F.eks. mine egne prosjekter gjør også akkurat dette, som er ganske viktig på X.org siden den lager noe hinsides med events ved musebevegelser, hvis jeg skal ha en sleep der kan det skape forsinkelser (på musen altså), derfor er det vanlig å polle for events konstant. Tilsvarende vil en rendering-thread ligge konstant og mase på om driveren er ferdig.

Ah, ok. Dette visste jeg ikke. Bra forklart.