Sign in to follow this  

single threaded vs Multithreaded applications

This topic is 4178 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am still puzzled on the differences in single and multithreaded applicatons. In VS 2005 the options default to Multithreaded apps right? Well, what exactly are the benefits of multithreaded applications? Are they faster, slower or just the same speed as single? Should I buy VS 2005 because they compile multithreaded apps? Do games work better in multithreaded apps? Please could someone explain this me. will appreciate any responses. thanks

Share this post


Link to post
Share on other sites
I think you are confused about something. In VS, there is no such thing as an app being singlethreaded or multithreaded by default; threading is always something you have to add yourself.

What VS lets you choose is whether to use the singlethreaded version of the C and C++ runtime or the multithreaded ones. The multithreaded ones do certain things that make the code using it more reliable in a scenario with multiple thread. This means avoiding globals and statics, as well as adding some locking in certain places.

Share this post


Link to post
Share on other sites

It is possible to create a game program which doesn't use multithreading. Multithreading becomes handy in situations such as creating a GUI which needs to be responsive all the time even if the program otherwise is performing heavy calculations

or perhaps you have a music streamer which is constantly loading data from disk and playing it. If you didn't use multithreading, you would constantly need to call some sort of update function which would do the task.

Also, similar things apply to networking where you need constant observing of incoming data.

Programming multiple threads isn't easy. They produce hard-to-understand bugs, deadlocks etc. Ie. lots of planning is required about the communication between threads.

As far as I know, new multicore CPUs are able to take over separate threads and thus, are capable of performing better. It is said, that in the future you'll need to do multithreading in order to get all the performance from the CPU.

Share this post


Link to post
Share on other sites
MultiThreaded apps are "better" and "worse". Arild Fines is right about there being no default threading to an app
in VS2005. The default app setup is thread safe, and the CRT(or something in the framework) tends to start up several threads
even on the console apps I do.
BUT, there is no real benifits or detrements to speed on a modern system because of this.

WHAT you need to look at is the art of spliting your own application's work into threads. This is often only doable
in a manual fassion, though there are particular applications where a good compiler(2005 professional and up if I remember right)
can support compile time thread codeing like OpenMP.
If done correctly, multithreading your program can greatly increase performance. You can split data processing across multiple CPU's. So one CPU can do graphics and the other Physics and AI. Or you can
batch work so that each CPU does processing for only part of the whole data set(think web servers, or physics simulations of lots of particles).
ALSO, threading can improve the code in cases where you have intermittent action, like Demus79 said about the music,
or even the network code.

BUT, threading can slow your application down if done wrong. Bad technique can result in data contention between threads,
thus slowing everything down. Threads can thrash the CPU's cache reducing performace, and threads add some overhead
if you have more threads that need the CPU than you have CPU's to run the threads on.
Good programming practices can reduce problems in all but the final case, where you have to test on the lowest end system
to be sure the threads give the boost on a multi-core, but dont kill your single-core computers.

LASTLY, not everything can be threaded. Not everything should be threaded. Starting 1000 threads for 1000 network connections
over TCP/IP is NOT the way to go. Trying to thread a tight loop sort like bubble or insertion is going to be harder than
threading a recursive devide and conquer sort like heap or quick sort. Multithreaded programming is not easy.
Go try some of the top coder Intel-Multithreading competition stuff. There is a lot more to threading than initially appears to be.
But the benifits can be worth the costs in complexity.

Share this post


Link to post
Share on other sites
In VS 2005 they have completetly removed the none multithread capable runtime libraries because now days the speed difference is minimal.
If your code is single threaded there will be a small performance hit on going over to 2005 because of it. However my guess is that it's negtiable. You will probably rather gain speed from all the new optimization techniques they use.

Share this post


Link to post
Share on other sites
Sign in to follow this