[SMP] tool voor het zetten van affinity.

[Verwijderd]

Hoi allemaal,

Na een poosje hier en daar zoeken voor het zetten van de affinity mask voor processen heb ik een tooltje gevonden die ik nog niet op het forum ben tegengekomen.

Ik had wel al het tooltje Seesaw gevonden op dit faq, wat zeer handig is trouwens.

ftp://ftp.microsoft.com/b...nt-public/tools/affinity/
Met dit tooltje is het mogelijk om de affinity op services te zetten, en deze blijven vervolgens ook er op staan na een reboot.

Met dit tooltje heb ik ook een probleempje opgelost waar ik af en toe last van had.
In sommige games was het geluid via mijn SBLive! zeer choppy. Nu heb ik met behulp van dit tooltje mijn SBLive! process naar cpu0 gezet, en tada geen choppy sounds meer op mijn systeem.

Verder ga ik dit weekende even kijken of ik een beetje performance winst kan boeken als ik mijn GF4 alleen op cpu1 laat draaien. Terwijl ik met seesawpro alle andere processen op cpu0 zet.(weet namelijk niet of de detonaters multithreaded werken)
Dus als het meezit dan horen jullie na het weekend mijn bevindingen.


Hopelijk hebben veel mensen die Dual draaien hier baat bij.


Verder ben ik ook nog bezig met een tooltje (met behulp van de source van seesawpro) waarmee ik in het rechter muisknop menu de optie krijg "Uitvoeren op CPU1)
- Deze start de geselecteerde exe uit op cpu1
- Zet alle andere processen naar cpu0
- start het geselecteerde process in realtime of high priority.


Veel plezier

[maratropa]

hi, ik heb met de "microsoft affinity tool", te downloaden bij microsoft hetzelfde gedaan voor mijn IRQ van mijn geluidkaart, die is nu gebonden aan 1 processor. (hiermee lock je dus IRQ en geen processen aan een cpu)

http://support.microsoft....2/8/67.ASP&NoWebContent=1

Verder lijkt het me het all round niet echt slim om processen aan maar 1 CPU te binden. Op 2CPU lopen wat windows programeurs die er wat meer van af weten, dit is wel handig stukje.

"pmurgs: The scheduler already includes code to try to keep threads on the same CPUs where they previously ran, for exactly that reason.

The reason constraining an app to one CPU is often bad is that you can't control every other thread in the system. System threads in particular cannot have affinities assigned. Now suppose one of the high-priority system threads is running on the CPU you've chosen for your game. Guess what -- the game's thread can't run in that CPU until that thread voluntarily waits ("blocks" in Unix parlance). And since you locked the game out of the other CPU by setting its process affinity, it can't run in the other CPU either!

Granted that bouncing to the other CPU isn't the best thing for performance, but not running at all is almost always worse still.

Also, the hit from running in the "wrong CPU" (as far as cache investment is concerned) is not necessarily that of having to go all the way to memory. Remember that the caches can (and indeed must) provide data for each other. If I'm running in CPU 1 and the memory I want is cached in CPU 0, CPU 0's cache will supply the data to CPU 1's cache. This of course isn't as fast as it would be if the data were in my CPU's cache, but it's a lot faster than going to memory... it's sort of like a level 3 cache.

Finally, note that most apps these days, including most games, are multithreaded (even if they haven't been decomposed so that they run faster on MP systems, they nevertheless are multithreaded). Now a game will usually have one thread (the main rendering engine) running just as fast as it can, while other threads are waiting a lot, reading the UI devices and emitting sounds and so on. By constraining the game to one CPU you are saying that of all of its threads, only one can run at a time. As many have noted, most games don't achieve any more fps on MP, and that is because the rendering engine is single-threaded. But that doesn't mean that having another CPU to run its other threads on won't help; fps is only one measure of a game's performance, and says nothing about its responsiveness to user input."

en wat verder:

"Despite what I wrote above, I didn't mean to say that pmurgs was wrong; what he wrote here, and the reasons he gave, are still true. Whether you will get more fps or not depends on what else is running, how the game is coded, and many other factors. 2k/XP's "soft affinity" and "previous processor" mechanisms do tend to reduce the amount of gratuitous thread migration among CPUs, but of course they can't always do a perfect job.

Sometimes the cache coherency issues are dominant; sometimes the CPU availability issues are dominant. The same game with its affinity set might get more fps on one machine, but fewer in another. Sometimes even a single system will get into different patterns of scheduling behavior at different times, and the results will be different in each. (This phenomenon is not unlike the "strange attractor" principle in chaos theory.)

Heck, try it - it's an easy experiment to do. It shouldn't be a huge difference either way."

[ Voor 25% gewijzigd door maratropa op 27-06-2003 12:16 ]

[Verwijderd]

okz.... klopt als een bus..
ik had mijn videokaart op cpu1 gezet en de rest van de hardware op cp0.
Pc starte netjes op.....
Alleen hij kan in deze modus geen direct3d vlakken meer aanmaken.

Helaas.... Helaas.....
Maarja als ik nog iets tegenkom dan laat ik het jullie wel horen