Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
Hi,
I am working on implementing multithreading in application.
My application processes millions of records per run/execution. I want to distribute this task to number of threads to improve performance. All threads will remain busy.
 
In this case is it wise decision to spawn number of threads = number of available processors ??(e.g. Four threads on quad core machine)
 
If i make more threads, will it hamper the performance ??
 
Regards
Prafulla Vedante
Posted 29-Jun-11 4:05am
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

There is no easy correct answer to the question.
 

It really depends on if/whether your threads are ever going to be waiting for i/o (disk access, network, etc.) and how long those waits will be versus the cost of switching threads.
 
If your processor core is only ever going to be waiting on data from RAM, then it's unlikely the processor can switch threads faster than that.
 
If on the other hand, the thread is going to be waiting on data from some network attached database, then the system might be able to switch threads and get something useful done while waiting for it. In that case it might be useful to have twice as many threads as cores.
 
The other thing to take into account, is what (if anything) else is going to be running in the system, and is the OS going to be a lot of other things? And how does the OS assign cores? (In which case it might turn out that 1 less thread than the number of cores might be best.)
 
The best thing to do is try various numbers of threads and see what gives you the best performance. I'd try a couple of different test cases. If you have N cores, I'd try 1-thread, N-1 threads, N threads, N x 2 threads -- and see what gave you the best performance consistently. If N threads and N x 2 threads give similarly good results, try N x 1.5 and N x 3.
  Permalink  
Comments
PrafullaVedante at 30-Jun-11 3:05am
   
Thanks , my 5
It works best for 3 threads on quad core :)
TRK3 at 30-Jun-11 9:33am
   
Great. Thanks for sharing the results. I suspected 3 might be optimal, but it's nice to have proof that my intuition was right. :)
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

I follow a couple of rules of thumb, depending on the application type. Assume N is the number of cores / processors / separate CPU execution paths.
 
If the application is "compute bound", that is, mostly computation cycles, then use N threads.
 
If the application is "I/O bound", that is it spends most of its time reading or writing data, regardless of the I/O speed (disks, network, etc), then start 2 threads.
 
If the application is a mix of some I/O and some computes, then it really depends on where the bottleneck is. For exampls, if the I/O is to / from a remote database (SQL, etc) then there's no benefit to many threads. If the I/O is local, then you can use up to N threads depending on host cache / disk writeback cache. That is, if host caching buys you anything, use more threads.
 
Be aware that some applications, even compute bound ones, slow down when multiple threads are used. For example, heavy CString object use actually bottlenecks waiting for memory allocation / deallocation so no real progress is being made while the CPUs burn cycles.
 
So, know your applications requirements and possible bottlenecks before throwing N, 2N or more threads at it.
  Permalink  
Comments
PrafullaVedante at 30-Jun-11 3:04am
   
Thanks for your answer my 5.
 
I have cpu bound application. It gives best performance for 3 threads for quad core.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Maciej Los 295
1 OriginalGriff 249
2 Sergey Alexandrovich Kryukov 205
3 Aajmot Sk 197
4 Sinisa Hajnal 176
0 OriginalGriff 7,800
1 Sergey Alexandrovich Kryukov 7,072
2 DamithSL 5,604
3 Manas Bhardwaj 4,986
4 Maciej Los 4,790


Advertise | Privacy | Mobile
Web02 | 2.8.1411023.1 | Last Updated 29 Jun 2011
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100