Overhead of sf::Thread::Launch

[Xander314]

I am writing a class to handle 'per frame' multithreading, i.e. graphics, physics, audio etc operations to be run each frame. I then call this every frame:

Code: [Select]

for (unsigned itr=0; itr<ProcessLists.size(); itr++)
    ProcessLists[itr].first->Launch();


where ProcessLists is a map:

Code: [Select]

std::map<sf::Thread*, ProcessList*>
and ProcessList is a class I wrote which defines the list of operations to be carried out on that thread.

My question is: is it inefficient to call sf::Thread::Launch every fram?. Does this function create the actual (Win32) thread etc., or is that done in the constructor? Is there a large overhead associated with sf::Thread::Launch?

Thanks in advance for any help.

[Laurent]

My question is: is it inefficient to call sf::Thread::Launch every fram?

I don't know, but I think so.

Does this function create the actual (Win32) thread etc.

Yes, nothing's done in the constructor.

I think you're doing it wrong. You should rather have a pool of threads that wait for "jobs" to execute, rather than launching a new thread everytime you have a task to execute.

And why don't you even let each module (graphics, physics, ...) running in its own thread rather than doing it every frame?

[Xander314]

Okay, thanks for your help - I really appreciate it. I shall do as you suggested with the thread pool  

why don't you even let each module (graphics, physics, ...) running in its own thread rather than doing it every frame?

I did it this way since it seemed to be the easiest way to synchronise the threads.

OK, so I shall give each of the modules a separate thread at the start. I still need to synchronise them so that they have all completed one frame's computations before going on to the next frame, right? (Please feel free to direct me elsewhere if you feel I'm getting off the subject of SFML...)

[Laurent]

OK, so I shall give each of the modules a separate thread at the start. I still need to synchronise them so that they have all completed one frame's computations before going on to the next frame, right? (Please feel free to direct me elsewhere if you feel I'm getting off the subject of SFML...)

Not necessarily. Input can run faster than graphics, graphics can run faster than physics, etc. there's no need to make everything run at the same speed.

But first... are you sure that you need to put everything in threads? It's a complicated thing, and if you don't really need to, or if you're not comfortable with multi-threading techniques and problems, you shouldn't do it this way.

[Xander314]

I know they don't run at the same speed, but once you have rendered the frame you can't render objects the next frame until you've finished computing physics their new positions.

Nonetheless, you are probably right. It might be best to leave my engine as single core for now. Otherwise I'll probably get the multithreading wrong anyway... :?

Thanks again.

[Mjonir]

I know they don't run at the same speed, but once you have rendered the frame you can't render objects the next frame until you've finished computing physics their new positions.

Not necessarily, I'd say it depends on your game.

In my own project (shmup engine), all sprites are objects relatively independent from each other. It doesn't matter if I render a sprite a pixel left or right from the position it should have in the current frame.

Thus, I can have my simulation thread (computes the new coordinates of every object) run at the speed I want, the only thing that'll change is the precision of the simulation. The displaying thread also runs at its own speed and is completely independent, just displaying the sprites at their new coordinates at its own speed.




On that subject, my own question: if I have a small task to do once in a while (like deleting stuff I don't need, or moving something on the screen), is it really less efficient to launch a thread every X ms that does the job and then disappears than to have a permanent thread that sleeps for X ms after its job is done? Or is it roughly the same?

[Xander314]

Oh, I see! Thanks Mjonir - that has made things clearer.

if I have a small task to do once in a while (like deleting stuff I don't need, or moving something on the screen), is it really more efficient to launch a thread every X ms that does the job and then disappears than to have a permanent thread that sleeps for X ms after its job is done? Or is it roughly the same?

Do you mean as I did in my original post? Laurent suggested the Launch function may be performance heavy so, while I am not very sure about multithreading yet (hence this forum post...), I am guessing it is worse to keep relaunching the thread. How big are you intending X to be?

[Mjonir]

Do you mean as I did in my original post? Laurent suggested the Launch function may be performance heavy so, while I am not very sure about multithreading yet (hence this forum post...), I am guessing it is worse to keep relaunching the thread. How big are you intending X to be?

It's hard to tell, but let's say between 1/60 second and a few seconds. I'm wondering if there would still be a significant overhead compared a sleeping thread. Laurent said it might be worse, but I'm wondering anyone knows if it's really significant in this kind of situation. If not, I guess I'll try it myself

[Xander314]

If you do try it, can let us know how it goes - I too would be interested in how big the actual performance losses are.

[Wizzard]

Code: [Select]

void ThreadFunc()
{
    while (!ShouldRun)
        sf::Sleep(0);

    // Do stuff here!
}