[blog] Thread Counting...
#11
In .NET world we usually do Thread.Sleep(50); to avoid letting the thread eat up all the CPU.
Reply

Sponsored links

#12
Ok now emu works only with 2 cores, gradually people buying 4 cores cpu and others multicore cpu if it is difficult to make multicore support for emu is it possible to make separate streams for sound or graphics?
Example: main streams eerec, vurec, microvu – to mtgs (2 core usage), graphics, sound, controller, cdvdrom – to others free cores.

sorry if I do poorly explained
Reply
#13
(12-22-2009, 03:41 PM)Ravenheart Wrote: In .NET world we usually do Thread.Sleep(50); to avoid letting the thread eat up all the CPU.

The problem with this is you're going to burn some multiple of 50 units of time (milliseconds I think) and that is probably far too coarse-grained for something like this.

To borrow Air's code chunk,
Code:
volatile bool IsRunning = true;
StartThreadedAction();
while( IsRunning )
    Thread.Sleep(50); //Sleep 50 ms, then check again
//Carry on
is what your pseudocode would look like if I understand your idea. But if the action takes ~51 units of time to complete, the loop is going to be asleep for a full 100 units of time before it wakes up and can continue. This is probably unacceptable for something that needs high-performance. You're still polling the variable, and that's the heart of the problem.

Quote:Example: main streams eerec, vurec, microvu – to mtgs (2 core usage), graphics, sound, controller, cdvdrom – to others free cores.

This has been suggested before, but it's incredibly hard to seperate the things in a way that would make a real difference. As it stands all the work is done by two cores, one core for the graphics and the other core for everything else. Trying to seperate pretty much anything else out is
a) really difficult to do correctly, and
b) not guaranteed to give any boost, and may well end up hindering performance.

So far the best use for more cores is to throw it at the graphics plugin in the form of the software rendering threads.
"This thread should be closed immediately, it causes parallel imagination and multiprocess hallucination" --ardhi
Reply
#14
is the new threading option it VirtualDub not a sample? or is it completely different
Reply
#15
I hate to perform necromancy..but couldn't you use a binary semaphore?
Reply
#16
out of morbid curiosity wouldent it be much more effective to off load th GS onto our modern gpu's via cuda or sum such. to me gpu doing emu of a fellow gpu would make more scence exspechely with more and more gpu's becomeing cuda ready ( or whatever ati calls that abelity on there cards ).
Reply
#17
The GS is pretty much the opposite of your GPU. It is software based so what you suggest is very hard to impossible.
[Image: newsig.jpg]
Reply
#18
(03-27-2010, 01:53 PM)Bositman Wrote: The GS is pretty much the opposite of your GPU. It is software based so what you suggest is very hard to impossible.

so what is the gs ?
Reply
#19
Google can give you amazing results.
http://en.wikipedia.org/wiki/Graphics_Sy...ifications
[Image: newsig.jpg]
Reply
#20
(03-05-2010, 07:15 AM)NoEffex Wrote: I hate to perform necromancy..but couldn't you use a binary semaphore?

I agree.

Air, the old setup used would have had horrendous performance if these actions typically took longer than a thread's quantum.

Code:
volatile bool IsRunning = true;
StartThreadedAction();
while( IsRunning );
// When the above while() exits, the ThreadedAction is done.

Using a semaphore shared between threads would be:

Code:
//IsRunning is your semaphore that you've passed as a reference to each thread.
Down( IsRunning ) //Attempt to take the lock, if you fail this function puts the thread to sleep until the lock is available.
StartThreadedAction();
Up( IsRunning ) // Release the lock, signaling completion of the task and wake up a sleeping thread if one exists..

(If you want multiple threads to work in unison under the lock, and know it's possible to do safely, go ahead and use a counting semaphore instead)

The binary semaphore has the decency to put the other threads to sleep. Putting threads to sleep and waking them again when it's their turn is far more efficient in the overhead department.

Note: If I've horribly misunderstood what the problem is, feel free to hit me. It's 3:30am, and I honestly am about to drop. =p
Reply




Users browsing this thread: 1 Guest(s)