Hardware-emulering til single core?

[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 alle 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..men det burde jo være "mulig" burde det ikke?

[geir__hk]

Nå er ikke jeg noen programmerer og kjenner heller ikke til dine kunnskaper.

 

Dersom du ser på f.ex Winrar og 7-zip så er dette gode eksempler på pakkeprogrammer som ved å benytte flere tråder (særlig en tråd pr kjerne) øker ytelsen betraktelig.

 

Men som du nevner over, så må det finnes rutiner for å holde styr på rekkefølgen. Nettopp derfor vil man ikke oppnå mangedobling av ytelsen i samsvar med det antallet kjerner det er tilgang på. Har du 7-zip på maskinen din så kan du enkelt kjøre benchmark og se hvordan ytelsen påvirkes ved å benytte ulikt antall tråder. I andre "tilsvarende" programmer kan ytelsekurven fremstå noe annerledes.

 

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

Dette skal godt gjøres, da du som regel har mye død-tid hvor cpu må vente på å få tildelt oppgaver.

 

Men siden du er interressert i å utnytte CPU'en din maksimalt og "til enhver tid" så foreslår jeg at du tar en kikk på f.ex World Comunity Grid. Det er en av flere organisasjoner som ønsker å utnytte datakraften til maskinen din (min óg) til å finne kurer til kjente sykdommer, samt en del andre veledige formål.

[Gjest Slettet+6132]

Var kanskje ikke helt det jeg tenkte på, men det jeg i hovedsak mente er i kjølvannet av at veldig få pc-spill bruker flere enn 1 eller 2 threads. Ofte pga. porting og at det rett og slett er vanskeligere nettop fordi man bl.a. må passe på nettop det eksempelet jeg kom med. Derfor hadde det kanskje vært bra for bl.a. spillinduistrien på PC at det var enklere å dra mer CPU-ytelse ut av maskinen.

 

Aner ikke noe om til hvilken grad det er mulig og hvilke pro's / cons som vil følge med det i form av total cpu-ytelse etc, men var noe jeg satt og tenkte på i dag og trenger litt input ^^

[N o r e n g]

Jeg er på ingen måte en ekspert, men dette er mine tanker om problematikken:

Det er rimelig enkelt å kjøre to tråder samtidig (fyr opp paint og notepad så er du igang,) det som er vanskelig (i spill) er å få disse til å kommunisere mellom seg raskt nok.

 

Si at du har et online FPS og fire kjerner, dette må gjøres et visst antall ganger i sekundet:

Spillregler: hitdetection, skade, AI...

Bildedata for skjermkort å tegne: hvilke 3D-modeller er i bildet

IO til serveren på nettet: hvem har flyttet seg hvor? Har jeg gjort noe?

Fysikk: er jeg i lufta og faller? Må en kurv flytte seg fordi den granaten sprengte?

 

For hvert bilde som tegnes må dataene oppdateres i en gitt rekkefølge:

Loop:

Inndata fra serveren må hentes.

Spillregler

Fysikk

Utdata til serveren sendes.

Bildedata regnes ut

Bildedata omformes til et forståelig maskinkode for skjermkortet gjennom DirectX/OpenGL

Skjermkortet kalkulerer grafikk

Bildet kommer på skjermen

Input hentes fra mus og tastatur

Slutt loop.

 

Noe av dette kan parallelliseres til en viss grad: man kan dele opp hitdetection over flere kjerner, man kan regne ut eksplosjoner med et bilde forsinkelse (dette er strengt tatt ikke et problem med tanke på granater og eksplosiver) og dermed avbelaste fysikkdelen totalt til en eller flere kjerner, men du kan ikke utføre hitdetection før du har fått inndata og du kan ikke lage bildedata før alt annet er klart.

 

Problemet oppstår når man skal hente dataene fra disse andre trådene, å skrive dette til en fil vil ta et mange millisekunder. RAM vil ta noen mikrosekunder, men du sitter fortsatt med problemet at de fleste av utregningene er avhengige av tidligere data i syklusen, tida det tår å sende ut data og hente disse inn igjen kan fort bli like lang som om man hadde bare gjort alt på en kjerne. At vi ikke ser en enorm forbedring i latency hjelper heller ikke.

 

Prinsippet bak Bulldozer med delt cache kunne blitt veldig bra for spill, men problemet her er at den er stor og treg: hadde vi fått mindre cache med en tredjedel så lange tilgangstider hadde saken vært totalt annerledes for spill. For oppgaver som kompresjon av filer og lignende er ikke dette et problem siden det er lett å fordele oppgaven så hver kjerne tar sin bit av fila og kjører avgårde.

[007CD]

Andre problemer er applikasjonslag det hele skal igjennom også.

Alt legger til forsinkelse og spiser ytelse, det å forsøke å splitte opp lasten i flere tråder i hardware blir også vanskelig.

For å gi ett eksempel, kan man begynne med beregningene for skade av den kula som traff Ai'en i hodet før spilleren har siktet seg inn og avfyrt skuddet?

Bare for å sette det på spissen.

[Stigma]

Siden andre her allerede har skrevet litt om selve problematikken så kan jeg vel bare kjime inn med at kort sagt så nei - det finnes (så langt ihvertfall) ingen løsning som kan oppnå en såkallt "reverse-hyperthreading" som det gjerne kalles - altså at flere fysiske kjerner fungerer som en enkel logisk kjerne.

 

Som det nevnes så er hovedproblemet at i alle programmer - og spesiellt interaktive programmer så er noen operasjoner avhengig av andre - og ergo så finnes det ingen universal måte å bare fordele lasten over mange kjerner.

 

Jeg tror dette sansynligvis er et uløselig problem som vi bare må jobbe rundt. Det nærmeste man kanskje vil kunne komme til noe slikt måtte være dersom det senere blir laget virkelig smarte frameworks og compilere som kan analysere enkel-trådet kode og automatisk lage multithreadet kode ut av det ved kompilering. Da vil det jo fremdeles være snakk om multithreading og derfor ikke egentlig det samme - men for programmeringen sin del kunne dette vært utrolig tidsbesparende dersom løsningen faktisk fungerte godt nok og kunne optimisere tråder minst like godt som et menneske kunne. Da kunne programmereren slutte å måtte tenke på multithreadingen (som kan være meget kompleks å optimisere) og spare mye tid og krefter som heller kunne brukes på programmet funksjonalitet mot brukeren.

 

Etterhver som vi på sikt vil begynne å migrere over til CPUer med 16+ kjerner så vil behovet for en slik teknologi utvilsomt bli større og større da det vil kreve mer og mer for å manuellt lage flertrådet kode som kan effektivt støtte så mange kjerner. Dette er nok ikke umulig å oppnå - men det vil kreve mye research og utvikling. Så langt jeg vet finnes det allerede eksempler på slike systemer som demonstrerer konseptet kan fungere i prinsipp, men det er nok enda en god stund unna fra å være universalt nok og bra nok støttet og optimisert for allmennt bruk.

 

-Stigma

[Gjest Slettet+6132]

Siden andre her allerede har skrevet litt om selve problematikken så kan jeg vel bare kjime inn med at kort sagt så nei - det finnes (så langt ihvertfall) ingen løsning som kan oppnå en såkallt "reverse-hyperthreading" som det gjerne kalles - altså at flere fysiske kjerner fungerer som en enkel logisk kjerne.

 

Som det nevnes så er hovedproblemet at i alle programmer - og spesiellt interaktive programmer så er noen operasjoner avhengig av andre - og ergo så finnes det ingen universal måte å bare fordele lasten over mange kjerner.

 

Jeg tror dette sansynligvis er et uløselig problem som vi bare må jobbe rundt. Det nærmeste man kanskje vil kunne komme til noe slikt måtte være dersom det senere blir laget virkelig smarte frameworks og compilere som kan analysere enkel-trådet kode og automatisk lage multithreadet kode ut av det ved kompilering. Da vil det jo fremdeles være snakk om multithreading og derfor ikke egentlig det samme - men for programmeringen sin del kunne dette vært utrolig tidsbesparende dersom løsningen faktisk fungerte godt nok og kunne optimisere tråder minst like godt som et menneske kunne. Da kunne programmereren slutte å måtte tenke på multithreadingen (som kan være meget kompleks å optimisere) og spare mye tid og krefter som heller kunne brukes på programmet funksjonalitet mot brukeren.

 

Etterhver som vi på sikt vil begynne å migrere over til CPUer med 16+ kjerner så vil behovet for en slik teknologi utvilsomt bli større og større da det vil kreve mer og mer for å manuellt lage flertrådet kode som kan effektivt støtte så mange kjerner. Dette er nok ikke umulig å oppnå - men det vil kreve mye research og utvikling. Så langt jeg vet finnes det allerede eksempler på slike systemer som demonstrerer konseptet kan fungere i prinsipp, men det er nok enda en god stund unna fra å være universalt nok og bra nok støttet og optimisert for allmennt bruk.

 

-Stigma

 

Det der var spot on

 

Jeg vet forøvrig at det ikke finnes enda, men det trengs allerede, og jo lenger det tar før sånn teknologi kommer dessto mer tid vil gå til slik optimalisering for utviklerene. Får håpe at det kommer noen gjennombrudd for massene snart

Endret 15. desember 2011 av Slettet+6132