2 CPU's langzamer dan 1

[Verwijderd]

Nu mogen jullie doen een poging doen om:

aan mij uit te leggen

afkomstig uit dit articel: http://www.xbitlabs.com/mainboards/dual-duron/

Zou dit aan het mobo liggen/ slechte ondersteuning van spel/ OS of wat ??

Hun uitleg is nogal vaag, is dit ook het geval bij Intel MP systemen?

[Verwijderd]

Deze test zijn dus op win2000 pro gedaan... daar zal het dus niet aan liggen eerder aan de test proggies denk ik.

[Verwijderd]

Op vrijdag 30 november 2001 16:11 schreef mgfun het volgende:
Deze test zijn dus op win2000 pro gedaan... daar zal het dus niet aan liggen eerder aan de test proggies denk ik.

ze zeggen dat het probleem is dat de DMA mode "te vaak belast word" dat dan de cache van de 2 cpu's te vaak vernieuwd moet worden, maar waarom bedenken ze hier (AMD) geen oplossing voor?

[Wirf]

Spellen zijn niet gemaakt om op twee CPU's te draaien. dus krijg je alleen maar overhead van het gebruik van twee CPU's.

overhead zoals het moeten delen van de bussen (Geheugen bus, Front Side Bus) het moeten schedulen van taken op de CPU's en het feit dat zodra een taak gerescheduled word naar een andere CPU, dat dan de caches weer moeten vollopen.

dual CPU is ook alleen maar aan te raden als je zeker weet dat je er profeit van hebt. (server/programmeren/renderen/zwaar multitasken)

[Verwijderd]

sodeklere
dat is zeker vaag ja

al is het wel zo dat quake3 geen donder doet met smp

een collega van mij heeft een dual piii-800 en hij had maar 6 frames meer in een timedemo als hij in de quake console smp aanzette

(r_smp 1 geleuf ik)

[reddog33hummer]

volgens het artikel is het de dma en de driver van de videokaart.

Ik heb zo het vermoeden dat dat klopt omdat voor de opengl ook SMP drivers uitgekomen zijn. Met deze drivers hebben ze betere preformance naar de videokaart. Hier hebben ze duidelijk een normale driver gebruikt (die dus deze problemen kend).

[reddog33hummer]

Op vrijdag 30 november 2001 16:07 schreef DJ_PP het volgende:
Is dit ook het geval bij Intel MP systemen?

op mij oude dual celeron 500 (bp6) liep quake III wel veel harder dan op de celeron 500 van mijn colega.
Ik heb quake III nog niet op mijn huidige machine gedraait

ik denk nee, maar ik weet het niet zeker.

[Verwijderd]

Dual systemen zijn alleen nuttig in situaties waarbij veel threads tegelijk worden gestart en je die dus over 2 CPU's kunt verdelen ipv ze allemaal op 1 CPU te draaien. Denk hierbij bv aan een database server die bv 20 connecties heeft, en zo'n 20 queries moet draaien. Hij start 20 threads op met per thread 1 query. Een dual bak zal normaliter per processor dan 10 van die threads draaien. Je bent in theorie dan sneller klaar.

Hoe werken spelletjes? Niet met threads . 9 van de 10 spelletjes hebben een zg. 'gameloop'. In die loop zit je spel zolang het draait en doet het alles: game logic, input/output handling, sound logic en video rendering. Aangezien spelletjes video-driven zijn, dwz je hebt een vrij constante 'feed' van frames nodig (frames per second) en alles in je spelletje is daaraan ondergeschikt, worden spelletjes in hun gameloop zo getweaked dat ze op een 'normaal' systeem vlot draaien. Dit wordt veelal vrij banaal gedaan: men test hoelang op een 'normaal' systeem een (1) gameloop doorloop duurt. Dit is bv 50ms. Dan wordt er bv 10 ms ingeruimd voor de gamelogic, 20ms voor het renderen van de beelden etc. Dit alles gebeurt nogmaals in de gameloop, en dit is 1 thread.

Waarom gebruiken ze niet een soort 'kernel' in spelletjes die verschillende 'threads' scheduled, een thread voor de rendering van beelden, een thread voor de sound, een thread voor de i/o, een thread voor gamelogic etc?. Als men dat zou doen, zou een dual proc in theorie sneller kunnen zijn, immers, je kunt een paar van die threads op een andere processor draaien. Dit werkt echter niet goed om 2 redenen:

1) Je scheduler kan nog zo eerlijk zijn, je ontkomt niet aan zg. thread-starvation, op sommige momenten. Dit houdt in dat 1 taak zoveel 'tijd' vreet dat het de andere threads de processor ontneemt. Dit is in normaal OS gebruik niet zo erg, maar in spelletjes is dit uit den boze: denk je eens in dat je beeld voor 1 seconde volledig stopt of terugvalt naar 2 fps omdat de gamelogic eens even flink wat AI gaat doorrekenen... . Daarom gebruikt men afgeknepen 'timeslices' voor elk stukje logica van een game, zodat men zeker is dat ieder stukje aan bod komt in 1 frame. Sommige games doen het echter wel hoor, het is echter wel lastig het echt goed te krijgen. Mensen die jarenlang demos voor de PC en amiga hebben gemaakt, weten dat video timing essentieel is voor een goede beleving van wat getoond wordt, of dat nu spellen of grafische animaties zijn.

2) Bij multi-threading zijn veelal de threads onafhankelijk van elkaar, of althans niet zozeer afhankelijk van elkaar dat de een de output van de ander nodig heeft. In mn voorbeeld hierboven over de database met 20 queries zie je dat elke querie in principe onafhankelijk is van een andere query, hooguit via de cache, en dus de threads die die queries uitvoeren dat ook zijn. In een spel als Quake3arena is dat niet het geval. Carmack heeft in een .plan hier uitvoerig over gesproken en hij heeft verschillende dingen geprobeerd: threads in de gameloop en het opdelen van de gameloop in verschillende taken die dedicated op verschillende processoren draaiden. Het laaste was nog het 'snelst', maar nauwelijks interessant. Dit komt omdat in een game de verschillende onderdelen allemaal afhankelijk van elkaar zijn: de videorenderer en de soundlogic wachten op de gamelogic en de gamelogic wacht op de I/O (wat doet de player?). In Q3A heb je wel zoiets als de bsp-culler, die polygoonlijsten samenstelt die gerenderd moeten worden, maar als de renderer niet op dezelfde cpu draait, moeten die complete renderlijsten in memory worden gezet, de thread die die dingen gaat renderen moet alles weer inlezen vanuit memory, alle cache is verloren, en wat je in feite hebt is single CPU. Waar je een beetje snelheid wint zijn op die plekken waar dingen echt parallel kunnen worden uitgevoerd: softwaremixing van soundbuffers tijdens het renderen van videobeelden bijvoorbeeld. Of het bepalen van NPC gedrag per NPC. Maar heb geen illusies dat het met 2 processoren ineens veel sneller gaat.

Ik snap derhalve dan ook echt niet waarom men in vredesnaam met spelletjes die dual bak heeft getest. Geeft imho aan dat de reviewer geen moer begrijpt van 1) gameprogramming, 2) dual systemen en 3) multithreading.

Ik hoop dat het een beetje duidelijk is nu.

[White Feather]

Dit hele verhaal komt me bekend voor. De oude series Duron en Thunderbird zijn vrij brak in MP-opzicht. Als ze deze test hadden laten lopen op een Athlon XP, dan zou er een heel ander plaatje ontstaan. Als je Dual gaat, neem dan 2 XP's/MP's of 2 Durons op basis van de nieuwe core. Mijn IE is zo brak als een hond en daarom kan ik de vergelijking van een 2X TB tov 2X XP niet opzoeken, maar de XP is in zo goed als alles minimaal even snel en als hij trager was dan was het nooit meer dan 5%.

[Abbadon]

Op zondag 02 december 2001 11:37 schreef Otis het volgende:
...interessant verhaal....

Ik hoop dat het een beetje duidelijk is nu.

Ja, da's voor een n00b op game-interals gebied als ik wel verhelderend

Alleen, het verklaart nog steeds niet waarom een game op een SMP bak iets minder performed dan op een uniprocessor bak. Kijk, als zo'n game-loop gewoon dedicated op één cpu draait en OS processen op de ander, zit je ogenschijnlijk niet met vertragende cache coherency problematiek zodat dát geen negatieve invloed zou mogen hebben. Daarentegen kan ik me ook weer voorstellen dat het toegepaste protocol (MOESI) sowieso moet checken of dat ook het geval is (dat beide cpu's idd geen thread met gedeelde data hebben), en dan heb je dus wel te maken met extra verkeer over de point-to-point verbinding waarvan de game last heeft (ik ben ook maar aan het vrij associëren hoor ).
Overigens ben ik niet verbaasd; met de Intel SMP bakken kreeg je ook al soortgelijke resultaten. Anyhow, de keren dat ik m'n DualXP misbruik voor een game gaat het flitsend genoeg

[Verwijderd]

dat is 1 x 900 Mhz
en.....2 x 450 Mhz

cpu's .... niet zo raar dus

[sjuk425]

Op zondag 02 december 2001 11:37 schreef Otis het volgende:
blah..

Is dit een nieuwe FAQ?
Netjes hoor

[Abbadon]

Hmmm, overeenkomstig de games wordt er bij x-bit ook een lagere 3DMark2001 score gehaald door de dual's (logisch natuurlijk):



Máár, kijk ik bij gamepc.com naar zo'n test dan zijn de resultaten juist omgekeerd (en dat geld ook voor de gamebenchmarks):



en deze als tegenhanger voor de Q3A test bovenaan deze thread:



Wat betekend dit allemaal? Niks als je het mij vraagt, of dat de snelheid van de gebruikte cpu's en FSB (ten slotte lopen 1.2GHz AMD's met 266DDR t.o.v. 200DDR voor de 900's in de x-bit test) van invloed zijn, of dat de videokaart (GF2 bij X-bit en GF3 bij Gamepc) een bepaald effect heeft. Al met al zijn de verschillen extreem klein, ook bij de echte gamebenchmarks (behalve Q3A natuurlijk)