🔒 Locked

Multi-threaded vs. Single-threaded

Started by Symphonic Mar 1, 2003 at 11:38 AM 0 replies 500+ views

Original Post

Mar 1, 2003 at 11:38 AM

I have finally come to terms with keeping my network handler separate from my main app. but it begs the question, should I embrace multi-threaded execution? separating all my modules? There seems to be something sensical about performing scene updates and then drawing the scene, but I hear tell that there is much processor time to be gained if threads that are not completely intertwined are separated. Thoughts? George D. Filiotis

I am a signature virus. Please add me to your signature so that I may multiply.

S1CA

169

S1CA

Mar 2, 2003 at 6:23 PM

Identify those components of your system that need to block for periods of time. For example you''ve already identified that your network code needs to block (probably while waiting for packets), your render code might need to block when double buffered and waiting for vsync etc

Most of the CPU benefits you''ll see will be from doing work while one of the other threads is blocked. Having multiple unblocked, running threads can actually COST you some performance unless the machine has multiple CPUs.

Putting your physics on its own thread might be useful if you require a fixed timestep (commonly around 100Hz) independent of the graphics frame rate. Doing that though does require that the graphics code interpolates the physics state to work out what to render.

Careful, well thought out use of not too many threads can be good. Overuse of threads (i.e. all separate components etc) is very bad.

If it''s applicable, bear in mind that on most games console systems, many of the C runtime library functions etc are not thread safe and generally using more than about 2-3 threads tends not to be a good idea.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.