Gamen met multi-core processors: zinvol of niet?

Door Hielko van der Hoorn, maandag 14 maart 2005 19:26, 66 reacties • Feedback
Bron: AnandTech

Bij AnandTech is het tweede deel verschenen van een vierdelige serie waarin multi-core processors onder de loep worden genomen. Binnenkort zullen de eerste dual-core processors op de markt verschijnen, maar in hoeverre zal de tweede core effectief gebruikt kunnen worden in games? Op deze vraag probeert AnandTech, samen met Tim Sweeney (hoofdontwikkelaar van de Unreal Engine 3), een antwoord te vinden. Alvorens het zover is wordt in het artikel eerst uitgelegd wat threads zijn, hoe meerdere threads voor betere prestaties kunnen zorgen en welke mogelijke obstakels op de loer liggen.

Intel Dempsey-core aankondiging Tim Sweeney is van mening dat een tweede core zeker nuttig gebruikt kan worden door gameontwikkelaars. Hoewel er slechts één core bezig kan zijn met het aansturen van de videokaart zijn er verschillende processorintensieve taken die verplaatst kunnen worden naar de tweede core. Te denken valt onder andere aan AI-berekeningen, physics, animatie en de geluidseffecten. Hoewel het nog te vroeg is om harde getallen te presenteren verwacht Tim Sweeney dat de Unreal Engine 3 significant sneller zal zijn op een dual-core processorplatform.

Hoewel multi-core processors waarschijnlijk voor een nette prestatiewinst kunnen zorgen is het niet alleen rozengeur en maneschijn. Het ontwikkelen van multi-threaded software is aanzienlijk complexer en duurder dan het ontwikkelen van single-threaded software waardoor het deels slechts probleemverplaatsing is. In plaats van het hardwareontwerp wordt het softwareontwerp de kritieke factor om hogere prestaties te kunnen halen. Desondanks is het een technologie met erg veel potentie.

Reacties (66)

ikwilhet
14 maart 2005 19:31

Bij games ligt de bottleneck toch meestal bij de Video kaart. CPU heeft hier weinig invloed op (vanaf een bepaald niveau). Dus dan snap ik niet waarom dual core dan voor games prestatie winst oplevert?

Countess

Wetenschap

@ikwilhet • 14 maart 2005 19:32

er zijn genoeg games waar je boven een bepaalde videokaart geen extra FPS meer ziet omdat de cpu te bottlenek is geworden, zeker op wat minder hoge resoluties of zonder AA en FA

+2 98889
@ikwilhet • 14 maart 2005 20:04

Bij games ligt de bottleneck toch meestal bij de Video kaart. CPU heeft hier weinig invloed op (vanaf een bepaald niveau). Dus dan snap ik niet waarom dual core dan voor games prestatie winst oplevert?

Jij hebt duidelijk nog nooit nagedacht hoeveel rauwe CPU power er bij komt kijken om de collissions te testen in een 3D high speed shoot-m-up met heel veel objecten. Om dat wat deftig te doen is het 1 redelijk complex en heb je 2 veel power nodig.

henk_DE_man
@98889 • 15 maart 2005 12:20

Dit is toch eigenlijk niets nieuws?

Arcade systemen gebruiken al jaren lang meerdere CPUs. Tripple 68000 had je al in de jaren 80.

Op console gebied was de Sega Saturn een extreem voorbeeld van multi-cpu hardware. De general purpose CPUs waren een Dual Hitachi SH-2, maar er waren daarnaast vele andere co-processors aanwezig.

Of het door verkeerde marketting kwam, een slechte developper kit, of gewoon domme pech, maar zowel de consument als de developper

op het ding. Heel erg jammer, want de potentie was hoog.

Ik hoop dus dat het dual core of mischien zelfs wel SMT / dual core / dual cpu verhaal voor de PC games niet hetzelfde lot zal ondergaan.

+2 abraxas
@ikwilhet • 14 maart 2005 19:44

't aansturen van de graphics wordt veel ontzien door de gpu tegenwoordig, maar een game engine is meer dan alleen wat direct3D of opengl calls..

in een single threaded game engine (en dat zijn 99% van de engines) gebeurt er op 1 de cpu maar 1 ding tegelijk.. AI, geluid, physics, netwerk, input, etc... het ene wacht dus altijd op 't andere.

als dat dus parallel kan, is daar winst te behalen (je kunt per gerenderde frame theoretisch 2x zo veel uitvoeren op je cpu). en dat kan ook wel, maar lastig, omdat game engines vaak alles "per frame" afhandelen... parallel is dat dus enigszins problematisch, omdat de render-thread wel per frame alles doet, maar de andere threads vrolijk hun werk doen zolang ze daar de tijd voor krijgen van de scheduler.

hielko: het kan, maar dat wordt steeds minder dankzij steeds indrukwekkender wordende physics en AI, en het steeds simpeler aansturen van de gpu (d.m.v. shaders, geometry instances, displacement mapping, e.d.)

catfish: dat is echt niet te vergelijken.. een gpu is ontiegelijk parallel en kan dus vrij eenvoudig ook met meerdere cores (of gpu's) werken, omdat het verwerken van deze data gewoon van die aard is. het is niet voor niets dat gpu's van steeds meer pipelines worden voorzien. de vertices zijn nu eenmaal ontzettend goed parallel te verwerken.

Auteur +1

Hielko
@abraxas • 14 maart 2005 19:47

Volgens het artikel van AnandTech kan de overhead van alle DirectX API Call's en het OS in sommige gevallen ruim 50 procent zijn van de totale processor belasting. Best nog een flinke hap dus.

catfish
@abraxas • 14 maart 2005 19:59

kan wel zijn, maar 3dfx en nu ook nvidia slagen erin de gfx te verdelen over 2 identieke kaarten, dan moet dat voor cpu's ook kunnen

Jack Flushell

@catfish • 15 maart 2005 09:48

kan wel zijn, maar 3dfx en nu ook nvidia slagen erin de gfx te verdelen over 2 identieke kaarten, dan moet dat voor cpu's ook kunnen

Kwestie van totaal niet weten waar je over blaat.
Een scherm in 2 stukken verdelen is stukken eenvoudiger dan software maken dat dual threaded is.

Bovendien zijn de prosessormakers er DUS al in geslaagd dual cores te maken...

Na ja.. je reactie is zo

dat het gewoon moeilijk is erop te reageren...

Derice
@ikwilhet • 14 maart 2005 19:33

Probeer Flight Simulator 2004 eens. Die vind dat wel lekker hoor extra CPU power naast een dikke videokaart.

+2 _l_Arjan_l_
@ikwilhet • 14 maart 2005 19:34

Bij SLI is duidelijk de processor de bottleneck.

+2 Olaf van der Spek
@ikwilhet • 14 maart 2005 20:15

Bij games ligt de bottleneck toch meestal bij de Video kaart.

Er bestaan meer game genres dan FPS hoor. En zelfs bij FPS is de CPU niet altijd de bottleneck.

Heb je het nieuwsbericht over de physics processing unit gezien?
Zoveel CPU bottlenecks zijn er dus nog.

Denk bijvoorbeeld eens aan een RTS waar AI (onder andere path finding) voor honderden units moet worden gedaan.

Denk ook aan bijvoorbeeld achtergrondtaken (VoIP, p2p, etc).

Auteur +1

Hielko
@ikwilhet • 14 maart 2005 19:34

Daarnaast; juist doordat er nu meer power beschikbaar is kunnen er nu realistischere physics geimplementeerd worden, een betere AI etc.

nAFutro
@ikwilhet • 14 maart 2005 23:37

Als je bedenkt dat je soms met onboard geluid bijna 10% van de fps kan verliezen is een dual core toch wel een leuk idee. En anders kun je misschien ander processor taken tegelijk doen, encoden van muziek, beetje rommelen met vmware/virtual pc...

0 Ikke_Niels
@ikwilhet • 14 maart 2005 20:49

In geval van windowed spelen speelt je processorkracht ook een hele grote rol.

rtgo
14 maart 2005 19:35

De huidige games zullen wellicht weinig winst behalen met meerdere CPUs/CPUcores maar de toekomst ligt toch in dat type processors. En aangezien computers niet alleen voor hi-end games worden gebruikt zullen de ontwikkelaars zich toch maar moeten aanpassen.
Ik geloof zelf niet dat het uiteindelijk duurder wordt om spelletjes te ontwikkelen. De kennis voor multithread programeren neemt natuurlijk gewoon toe als het normaler wordt om het te gebruiken. Het zal dus wel een kwestie worden van door de zure appel heenbijten.

TheOneLLama
@rtgo • 14 maart 2005 19:56

Bedenk ook dat waarschijnlijk de consoles van de "grote 3" (in ieder geval Sony en MS) multicore zijn.

Sterker nog, dit zijn straks "in-order" procesoren, wat betekend dat als je huidige complexe code (zoals AI) erop zou draaien (die niet gebruik kunnen maken van de nieuwe snellere graphics / floating point / vector), de performance stukken minder wordt als op de huidige systemen. Het zal daarom cruciaal zijn dat er gebruik wordt gemaakt van parrallelisatie.

+1 solatis
@rtgo • 14 maart 2005 22:56

Precies! Parallel computing wordt met de dag normaler; tegenwoordig krijgt elke programmeur op z'n hbo of academische opleiding wel met threads en de bijkomende problemen ( synchronizations, deadlocks, race conditions, etc ) te maken...

Bijkomend effect is dat de softwarewereld zich steeds meer gaat beseffen hoe handig design patterns zijn; onderzoekers lossen lastige, generieke problemen op en beschrijven de oplossingen in de vorm van pattern languages. Deze kunnen dan in projecten gebruikt worden ...

cdwave
@solatis • 15 maart 2005 11:31

Parallel computing heeft niks met threads te maken. Je moet hierbij meer denken aan het gelijktijdig kunnen uitvoeren van berwerkingen die onafhankelijk zijn, zoals in het stukje (4 waarden optellen):

x := a + b;
y := c + d;
s := x + y;

In bovenstaand stukje code kunnen de eerste twee regels parallel uitgevoerd worden, want ze zijn onafhankelijk. De derde moet wachten op het resultaat van de eerste twee regels. Om hierbij over threads te praten is onzin - als je deze code door twee threads zou laten uitvoeren zou je meer CPU tijd verstoken in beheer van semaphoren (wachten op de eerste resultaten x en y) dan in de werkelijke berekening. Een "slimme" CPU zou dit door hebben en als hij over twee "ADD" circuits beschikt een bewerking als s := a+b+c+d de helft sneller kunnen uitvoeren (2 ipv 3 cycles nodig)

Patterns zijn een goed idee maar verspreiden zich als een kwaadaardige ziekte door de code door incompetente programmeurs die hun onkunde erachter willen verschuilen. Het doel lijkt tegenwoordig te zijn om zoveel mogelijk patterns in je code te stoppen, in plaats van gewoon te gebruiken wat je echt nodig hebt.

+1 SG
@cdwave • 15 maart 2005 19:09

Pattern moet je zien als een middel " om het wiel steeds opnieuw uit te vinden" tegen te gaan.
Pattern's zijn beproefde oplossingen voor bepaalde problemen. Wat in houd dat je weer wat inkort op software design tijd. Toverwoord is re-use. Wat goed is voor time to market.
Voordeel is je krijgt een robust en manageble design die ook redelijk uitbreidbaar is in een korte tijd.
Nadeel kan zijn Pattern's zijn niet toegespits op performance.
Maar dat hoeft geen probleem te zijn Complexe game design eisen een hogere orde benadering ivm design en managing ervan dit gaat te koste van wat snelheid maar men wint tijd en minder bugs door de systeem eisen ietje te verhogen.
Optioneel kan je in het design gaan hacken/optimizen voor performance zelfs zover dat het niet meer conform het design is door short cuts en veroorzaakt twee maal zo lange tijd Q&A testing. Dan als er een design aanpassing komt heb je grote problemen.

Game script engine geld ook het zelfde heel flexible. Verkort game ontwikkeling aanzienlijk, maar kost ook performance maar de voordelen zijn veel groter dan het nadeel.

Ik neem aan dat een beetje sucsesvolle Game software huis wel raad weet met pattern's en die ook optimaal toepast. Of heb je het over indie game developers. Die zijn vrij in hun doen en laten wat voor methode maar te gebruiken. en hebben nog vaak niet die ervaring van de gevestigde orde.

H!GHGuY

14 maart 2005 19:34

op zich zijn huidige games toch ook al multi-threaded?
alleen worden deze dan door 1 proc afgewerkt zodat er minder kans is op synchronisatiefouten.

of heb ik het hier fout?

ik denk echter dat een multi-core/threaded aanpak ook niet zo moeilijk hoeft te zijn.
als je de juiste taken in aparte threads stopt, kan je zo mooi knutselen om ze wat uit te balanceren en eventueel kun je met prioriteiten en pauseren van threads die tijdelijk klaar zijn wel tot een mooi vloeiend geheel kan komen. Maar dit is natuurlijk slechts een theoretische en simpel verpakte oplossing...

Hakker
@H!GHGuY • 14 maart 2005 19:37

er zijn maar weinig games die daadwerkelijk van meerdere cores gebruik maken... De Quake en Doom 3 engine zijn er een voorbeeld van maar daarnaast zou ik er zo snel niet meer 1 kunnen verzinnen.

zonoskar
@Hakker • 14 maart 2005 21:21

De DOOM3 engine is (was bij release van D3) niet multi-threading. Ik ondervond iig geen prestatie winst op mijn dual Xeon machine.

+1 cc bcc
@Hakker • 14 maart 2005 21:33

Doom 3 loopt op 1 cpu, en Q3 was wel multithreaded maar dat was bij een update komen te vervallen.

+1 SG
@H!GHGuY • 15 maart 2005 19:18

"op zich zijn huidige games toch ook al multi-threaded?"
Nee OS zijn al lang Multitread maar dan in time sliced schedular achter mekaar.
Apps en vooral games zijn vaak groten deels niet multitread.
Veel Games gebruiken mischien al wel een extra threadje voor taken die anders de boel platleggen zoals load thread's

Als je Load Threads een game SMP enabled mee bombadeerd dan klopt het wel

Maar 'n skiboxje op 'n XL wielbased sprinter Merc bus is ook geen load verbetering in tegenstelling tot een dubbel assige aanhangwagen.

Echt SMP is als je zware taken splits in thread''s

0 TBCdevil
@H!GHGuY • 14 maart 2005 19:37

ik ben ook van die mening, dit komt allemaal ten goede voor de steeds complexere architectuur die in games wordt gestoken.

+2 BenTheMan
14 maart 2005 19:37

Is het niet duurder omdat het een nieuwe manier van werken is en deze nog doorontwikkeld moet worden om er efficient mee om te kunnen gaan?

+1 mjtdevries

Wetenschap

@BenTheMan • 15 maart 2005 10:47

Je sluit de spijker op zijn kop.

De game-wereld heeft nul komma nul ervaring met multithreaded programmeren. En dat kost ze dus nu heel veel extra programmeer tijd omdat je op een andere manier moet gaan denken/ontwerpen.

Wat dat betreft is de game wereld vreselijk conservatief. Ook wat betreft AI bv. Dat kostte altijd veel te veel cpu tijd dus werd er gecheat.
Nu hebben we bij veel games cpu tijd over, maar nog steeds zitten AI's zwaar te cheaten.

Galciv dat door Anandtech werd aangehaald heeft een hele sterke AI zonder te cheaten. Maar als je het de developer vraagt dan vind hij het helemaal geen bijzondere AI.
Maar hij had gewoon geen ervaring met games, en ging dus niet automatisch een AI schrijven die zat te cheaten. En daardoor kwam ie dus met de beste AI die ooit in een game is gemaakt. Dat zegt toch wel iets nietwaar?

Overigens is Galciv ook multithreaded omdat de developers nooit in het stramien van het singlethreaden vastgezeten hebben. Bij OS/2 werd multithreading gigantisch gepushed, en als beginnende developers gingen zij dus automatisch threads gebruiken.

Wat dat betreft is het dan ook erg jammer dat Anandtech geen interview met Brad Wardell (ontwerper van Galciv) heeft gehouden, want hij heeft immers al vele jaren ervaring met multithreading in games.

Wat ook jammer is, is dat anandtech niet even heeft getest in hoeverre multicores enige zin hebben bij hedendaagse games. (Al was het maar een bevestiging dat het geen zin heeft)

+1 fidelio675
@mjtdevries • 15 maart 2005 12:10

Dat is zwaar overdreven. Elk spel wat netwerk/multiplayer ondersteunt gebruikt wel degelijk threads. Je kan netwerk communicatie echt niet singlethreaded afhandelen.
Dus ik denk dat het wel zal meevallen met dat nul kommal nul ervaring.

Sommige games zijn vrij eenvoudig, die updaten elk frame de positie van een tiental vijanden en de positie van de kogels die je hebt afgeschoten. Maar games met enkele honderden tegenstanders en ingewikkelde pathfinding kan de updates in een aparte thread uitvoeren, een voordeel is dan ook dat het blijft lopen zelfs al haperen je frames wat.

0 mjtdevries

Wetenschap

@fidelio675 • 15 maart 2005 14:38

Alleen heb je er geen zier aan dat netwerk communicatie multithreaded afgehandeld wordt, want dat vreet geen bergen cpu!
(Vandaar ook mijn opmerking over het testen van huidige games, want dan had je dat meteen kunnen constateren)

Wat betreft je opmerking over het gebruiken van threads in games ben ik het met je eens. Ik heb hier al vaak betoogd dat je op vrij simpele wijze effectief gebruik kunt maken van threads in games zonder dat je voor deadlocks bang hoeft te zijn.

Neem alle realtime spellen met meerdere tegenstanders. Voor elke tegenstander kun je een aparte thread gebruiken omdat die in realtime spellen toch onafhankelijk van elkaar de AI berekeningen moeten kunnen doen.
Voor met name vliegsimulators die altijd zeeer zwaar cpu limited zijn kun je al heel makkelijk grote presatiewinst halen op die manier.

0 ijdod

@fidelio675 • 15 maart 2005 15:17

Die multithreading valt denk ik in de praktijk nogal tegen. Dat de API en OS/drivers in feite aparte threads zijn is logisch, dat zijn feitelijk andere applicaties. maar dat wil nog niet zeggen dat dit in de game zelf ook multithreaded wordt gedaan.

Als ze de netcode op die manier scheiden, zou je ook al verwachten dat ze hetzelfde doen met de GFX en AI.

Rey Nemaattori
14 maart 2005 23:47

Is het niet mogelijk OS en applicatie te scheiden op hardware niveau? dwz OS + services/deamons en keline proggies(winamp oid) draaien op core 1 en de applicatie op core 2. Als de applicatie core overuren(zoals bij intensief 3dgaming) draait worden processen met minder prioriteit naar de OS core overgebracht tot applicatie core slechts 1 applicatie draait of beide cores even hard werken.

Voordeel: Je houdt enorm veel rekenkracht over omdat er minder geswitched hoeft te worden tussen threads.

Eigenlijk zou je in de prompt/bij install dan moeten aageven of het op de OS core of de applicatie core gedraait moet worden.Op deze fiets zou, als je bijvoorbeeld quake 3 opstart, de benodigde geluid en beelddrivers meegegeven kunnen worden aan de applicatie, zodat deze zonder tussen komst van het OS kan schijven en lezen van en uit de geluids of videokaart.

De geluidskaart(of videokaart) moet dan zelf bijhouden of een applicatie toegang krijgt(zoals bijvoorbeeld teamspeak, winamp & een game) of welke afgeketst moet worden indien alle kanalen in gebruik zijn. Zo zou je tijdens quake3 kunnen tabben naar winamp die door de OS core gewoon over het beeld word geschreven van de appliactie core(je krijgt dus beide te zien) tenzij bij het opstarten oid anders word aangegeven.

Maar ja, dan zul je de architectuur drastich moeten veranderen....

+1 mjtdevries

Wetenschap

@Rey Nemaattori • 15 maart 2005 11:24

Er is geen enkele reden om OS en applicatie op hardware nivo te scheiden.

ELK OS verdeelt de threads allang op de meeste efficiente wijze over de aanwezige processors. Daar is echt allang over nagedacht op het moment dat een OS multi processor support ingebouwd krijgt.

Wat jij voorstelt geeft een heleboel rompslomp (ook voor de gebruiker) zonder dat het enige winst oplevert.

Je kan het overigens zelf uitproberen als je dat wilt.
In windows kun je van elk process handmatig aangeven op welke cpu het moet draaien.
Daarvoor moet je naar de taskmanager gaan, rechtklikken op het proces en kiezen voor Set Affinity.
En dan zul je vanzelf merken dat je er niks mee opschiet.

Franckey
14 maart 2005 19:40

Dit geld niet alleen voor games maar voor alle software dat software speciaal ontworpen moet zijn om meerdere CPU's te gebruiken. Toch kan 2 CPU's in 1 systeem wel nuttig zijn omdat Windows zelf op 1 CPU kan draaien en alle app's op de 2e CPU gestart kunnen worden. Zo heb je minder last van het feit dat Windows steeds meer CPU tijd nodig heeft.

b3n666
14 maart 2005 20:08

Waarom maken zie niet een soort load balancer in de software? Dat gebeurt ook bij gpu's (sli en ati's versie daarvan). Het kan toch nooit zo heel veel werk zijn om een stukje software te laten checken of er 2 cores aanwezig zijn en als dat het geval is de taken te verdelen onder de cores.

Ik heb er niet echt veel verstand van ofzo maar het lijkt mij dat als je een soort driver voor multicores voor een game maakt dat dat nooit zo heel erg duur kan zijn. Plus dat je in de game zelf niks hoeft te proggen wat weer minder tijd kost en het minder moeilijk maakt. Het maken ervan kost dan wel weer tijd maar die was je toch al kwijt en op zo'n manier kan je het imo ook makkelijker upgraden.

+2 abraxas
@b3n666 • 14 maart 2005 20:12

wat jij voorstelt is helaas onmogelijk, omdat je in tegenstelling tot bij load balancing met afhankelijkheden zit... "normaal" in een game engine wordt het ene na het andere uitgevoerd.. hierdoor is de volgorde van wat er gebeurt 100% voorspelbaar.. multithreaded zal deze aanpak herzien moeten worden. geluid is afhankelijk van gebeurtenissen in de physics bijvoorbeeld, wanneer physics berekent worden en de frame nog niet gerenderd is maar de physics thread weer tijd krijgt, zal er wederom physics berekend worden.. betekent dit dat de vorige physics berekeningen genegeerd mogen worden? lijkt me niet, een collision situatie zal alsnog gerenderd moeten worden.. tis maar een voorbeeld, maar zo zijn er werkelijk duizenden te verzinnen.

Auteur +1

Hielko
@b3n666 • 14 maart 2005 20:11

Je vergeet iets; de taken die je hebt moeten wel te verdelen zijn over meerdere processors. Als je bijvoorbeeld als de volgende twee berekeningen wilt doen:

1) x := 10
2) x := x + 1

Dan heeft het geen enkel zit om instuctie 2 tegelijk met instructie 1 uit te voeren, want instructie 2 heeft het resultaat van instructie 1 nodig voordat ie kan beginnen.

kipusoep
@Hielko • 15 maart 2005 09:31

Misschien sla ik de plank volledig mis maar volgens mij klopte er iets niet:

1) x := 10
2) x := x + 1

Moet dat niet zijn:

1) x := 10
2) z := x + 1

Anders staat er namelijk

2) 10 := 10 + 1

phaas
@kipusoep • 15 maart 2005 09:37

Als x geen constante is, zie ik het probleem niet zo.

Steffy
14 maart 2005 20:13

Ik weet dat er in ieder geval 1 game is die er gebruik van maakt en dat is Quake 3. Vroeger draaide Quake 3 duidelijk beter op een Dual P3 weet ik wel, in de tijd van de voodoo 2 en 3. Of het zinvol was is een 2e maar voor de gein proberen was altijd leuk.

Of de extra proc zin heeft is ook maar de vraag, physics bv heeft men al een andere oplossing voor die zelfs sneller is dan een 2 CPU, die extra kaart die er voor op de markt gaat komen. En AI is ook maar de vraag, geen enkele game die ik gespeeld heb heeft AI, alles wat voor AI door moet gaan tegenwoordig is gewoon slecht, HL2 zou super AI hebben en dat was zelfs brak te noemen, van AI kunnen we nie spreken en kan me niet voorstellen dat de AI die nu gebruikt wordt berekent moet worden, of ze gaan er in de toekomst pas gebruik van maken maar dan is het zeker op dit moment voor AI niet nodig, Animaties lijken me ook geen processor vreten en geluid zal mits je een goeie geluidskaart hebt ook niet echt nodig zijn.

Kortom, ik twijfel er zelf sterk aan, op dit moment lijkt het mij niet zinvol maar misschien ligt het over 2 jaar anders hoor, dat kan best.

Makkelijk
@Steffy • 14 maart 2005 21:49

De meeste simulatie games hebben wel weer een AI die enorm veel processor tijd op eet, zoals RCT3. Dit komt niet omdat de AI zo geniaal is, maar omdat er zo veel individuen in je spel rondlopen.. die zouden hiervan kunnen genieten doordat je de AI dedicated op de ene processor doet, en de berekening van physica, graphics en geluid op de andere..

Bram77
14 maart 2005 19:49

Er zou eigenlijk een soort multi-thred applicatie moeten komen die er b.v. voor zorgd dat ook single-tread programma's multi- kunnen draaien. Een soort parser? (of noem je dat anders in deze situatie?) Anders wordt het produceren van software veel duurder (tijd rovender) en complexer.
In deze context denk ik dat het niet ten goede zal komen van de software. Als de software duurder wordt, zullen de meeste kopers kiezen voor de goedkopere, single-thread software. De producenten zullen dus proberen te zorgen dat het produceren van de multi-thread software zo min mogelijk tijd in beslag zal nemen om te kunnen concureren met de multi-thread software. Waardoor de kwaliteit van de software niet omhoog zal gaan.

0 wouter veltmaat
@Bram77 • 15 maart 2005 00:45

Voor oa OSX en Unix smaken is er vanuit het OS (extra) ondersteuning voor dual core hardware dus wat dat betreft hoeft ook het Wintel platform hier niet in achter te blijven.
Maar een ontwikkelaar kan niet zomaar lukraak processen aan verschillende CPU's aanwijzen. Daar moet nog steeds over worden nagedacht.

+1 mjtdevries

Wetenschap

@wouter veltmaat • 15 maart 2005 10:51

Sorry hoor, maar als je nou duidelijk totaal niet weet waar je het over hebt, houd dan gewoon je mond.

Elk OS dat ondersteuning heeft voor multi-cpu systemen heeft automatische ook ondersteuning voor multi-core. Voor het OS gezien zit daar namelijk geen verschil in.

Verder zal een ontwikkelaar ook nooit processen aan verschillende cpu's toewijzen. Dat is namelijk een taak voor het OS.
Het enige waar een ontwikkelaar voor moet zorgen, is dat er verschillende taken (threads) lopen zodat het OS die kan toewijzen.

En dan maakt het ook niet uit of je 1 of 2 of 4 processoren in je systeem hebt. Je OS zorgt er altjid voor dat de taken zo goed mogelijk verdeeld worden.

reddog33hummer
@Bram77 • 15 maart 2005 00:40

Het grote probleem is dat zodra je normale singe threaded programm's gaat parralleliseren je nondeterminisme krijgt. Als je iets dus paralell maakt verander je het gedrag. Om iets parallel te maken zonder dat het gedrag veranderd is bijna onmogelijk.

Franckey
@Bram77 • 14 maart 2005 21:00

Compilers zouden automatisch meerdere CPU's moeten gebruiken als er in een programma meerdere threads worden gebruikt. Dan valt het ontwikkelen van software wel mee, het hoeft niet moeilijker te zijn dan het nu is om met meerdere threads te werken.

Chappie
14 maart 2005 20:53

Hoe zit het met die oh-zo geweldig HT van intel? In dit geval zijn het 2 FYSIEKE cores ipv 2 virtual cores.

Als met HT al geen winst maakte, hoe wil je dan beginnen met 2 echte?

EvilWhiteDragon
@Chappie • 14 maart 2005 21:15

@Chappie_Pietje:
Bij intel (HT! heb je 2 virituele cores, wat er voorzorgt dat als 1 helemaal 100% bezich is dan is de 2e dateigelijk ook, dus dat helpt alleen als 1 thread een "core" niet helemaal vol krijgt, want dan kan een 2e thread uitgevoerd worden op de 2e "core".

Bij AMD (dual core) heb je 2 echte aparte cores waardoor je als je 1 thread hebt maar 1 core helemaal vol kan zuigen, de 2e kan dan NOG een 2e thread de volle 100% geven, dus in theorie 2 keer zoveel CPU tijd, alleen om er gebruik van te maken dan moet je daar wel rekening mee houden in je programma's.

0 mjtdevries

Wetenschap

@EvilWhiteDragon • 15 maart 2005 11:05

@Tha_Killer:

Je hebt helaas het concept van HT totaal niet begrepen.

Het cruciale van HT is dat 1 thread NOOIT een core 100% bezig kan houden.
Terwijl 1 thread 100% cpu usage heeft (zoals jij het ziet in het OS) zijn er nog grote delen van de core inactief, die gebruikt kunnen worden om een andere thread tegelijkertijd in te laten draaien.

Ik raad je aan deze uitleg van HT te lezen:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=1576&p=1

De mate waarin die core efficienter gebruikt kan worden is zeer afhankelijk van het soort threads dat draait. Als je meerdere threads hebt zit je vaak maar op 10% winst, maar bij bv exchange servers kun je 50% winst krijgen.
Maar heb je maar 1 thread die actief is, dan is de winst altijd 0%

Bij multicore (van zowel Intel als AMD) kun je uiteraard in theorie 100% winst krijgen.

Maar de voorwaarde dat er meerdere threads actief moeten zijn geld bij multicore/multi cpu net zo hard als bij HT.

Dus Chappie_Pietje slaat de spijker op zijn kop.
Als je bij HT 0% winst krijgt, dan kun je er gerust vanuit gaan dat je bij multicore ook 0% winst krijgt.

Moeilijker wordt de voorspelling als je bij HT 2% winst krijgt. Dan kunnen de threads toevallig ongelukkig zijn voor HT en heb je kans dat bij multicore/multi cpu de winst veel groter is.

Maar bij spellen zit je echt met 0.0000% winst met HT.

0 raoul4one
@Chappie • 14 maart 2005 21:06

Precies het zelfde liedje denk ik zo.
Software ondersteund het niet goed.
Zou beter kunnen werken, maar programmeurs blijven zo bezig.
Want daarlijk zijn ze bijna klaar en dan komt intel weer met gekke ideeen ...
Denk dat het daarom slecht wordt ondersteund.

1 2 3 Volgende

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

Gamen met multi-core processors: zinvol of niet?

Lees meer over

Nieuwste IT Banen

LOI ICT Opleidingen

Gerelateerde content

Sorteer op:

Weergave:

Reacties (66)