Do multithreaded apps only improve performance on computers with multiple CPUs?

No, it also improves performance on single cpu systems, imagine a thread waiting for some i/o data, like e.g i/o data or a simple Sleep(1000ms), then a second thread would be able to continue execution.

Edited by - Claus Hansen Ries on August 11, 2000 3:07:30 AM

Well, it may improve performance on single-cpu systems in very specific cases as Claus noticed (typically when a thread is blocked waiting for i/o, network input or any wake-up signal).

But spawning two computationally-intensive threads on a single-cpu machine won''t give any benefit. You may even lose some performance due to scheduling/synchronisation overhead.

Hi,

threads do not increase performance by default. You must be aware of what you want to achieve and if using threads is appropriate for this task. That means if you use threads for something which could be done without, it will slow your program down since everytime the thread scheduler changes the current thread there is a context switch performed which is on most OS an expensive thing. There are different way''s to implement threads, some OS support them from the Kernel like Windows and Solaris and on some others OS threading is faked by a library (user thread). The other thing why threading is not increasing performance by default is that your threads may use common resources. To prevent collision here you must use semaphores and mutexes (mutual exclusions), and these things are Kernel objects. To acquire and release a mutex is an expensive operation, if you doubt use a profiler and you will see. The rule of thumb should be, use threads only if absolutely neccessary. By the way there are some old fashioned tricks to avoid threads, by using a simple (socket) select statement which is still a good idea in most situations.

cu

Peter

Naive use of threads can even *decrease* performance on multiproc machines versus single proc machines. Peter hit the nail on the head. Anything that causes two threads to have to synchronize with respect to each other (i.e. one is waiting for another to finish before it can start) is going to hurt you. It takes a lot of careful design to get performance to scale well to higher number of processors.

IMHO, the best use for threads even on single proc machines is keep your UI responsive. Everybody has used some app and (say) tried to open a file and the app just hung for a few seconds because the disk/net/whatever is slow. If the app writer had kept thier UI on one thread and thier disk accesses on another it wouldn''t have been so bad for the user (it would have been harder on the developer though).

-Mike

Just write your app for BeOS and make it multi-threaded and the OS handles it. This is a very specific case of where it does speed performance.


B e S
It's Da BOMB Baby!!!

Edited by - wrenhal on August 11, 2000 4:11:09 PM

Multithreading usually improves a server''s performance, not a clients.

Say you have 100''s of people connecting to your server.

Having your main server game loop with only 1 thread is going to kill your performance. You''ll need threads to handle groups of players socket i/o''s, you need threads to handle NPC movenments/events, you''ll need a thread(s) to handle player logins, and various other threads to handle things like item creation/deletion and for persistant worlds backups.

If you''re progamming a game that''s not massively multiplayer then, for the reasons stated in posts above, don''t goto the hassle of multithreading your game.