How to determine the right ammount of threads

M

Malfunction

Junior Contributor
Joined
Dec 8, 2003
Messages
203
Location
Berlin, Germany
Let's say I have an array containing about 1000 objects.
Now I need to perform an operation with each object.

Since this operation requires some I/O and webrequests I don't want to go through the array sequentially but parallel using threads.

Using four threads I would probalby double the speed of the application and using eight probably quadrupling it.
At a certain point adding more threats the application will become slower as the number of threads would use all cpu power.

Right now i would just do some trial and error to determine the right number for my machine. Other uer would probably have total different experience.

Another solution would be to give the user the oportunity to change the number of threads through a slider.

My question: Is there a more professional solution for balancing the number of generated threads?
 
I see no reason that using multiple-threads would neccessarily give you much of a speed gain, unless you have a system with multiple cpus. You say it requires multiple I/O events and I could see how in theory accessing multiple files simultaneously could yeild a speed benefit. But you are still dividing all resources between the threads. I would personally think that on a single cpu system working with multple files in a loop in a single thread would yield the same if not better performance. Perhaps theres something I'm missing? I'm sure one of the Guru's will clear the matter up soon enough.
 
Cags, if processing the information involves any sort of latency (with the exception of latency in RAM access, I suppose), multiple threads allows you to grab ahold of much more of the CPU's power. While any one processing operation is waiting on something the CPU is ilding away. By introducing multiple threads you can get started on processing an item while others are waiting. When that first item hits a bottle neck, such as our HTTP request, you can get started on another item, and when that item hits the same bottle neck, there is a good chance that the first item will still be waiting, so we start a third thread and get the third item started. The resources aren't being divided, but rather spare resources are being recovered before they are lost.

Now, I'm no threading expert, but I know you don't want to dispatch each item to its own thread. CPU usage is not the only resource a thread consumes. If I didn't have a more experienced person to ask, I would stick with a reasonable number like eight threads, because even if you only push your CPU to 10% that is still an eight-fold gain in performance and keeps the resource-usage (threads, open web connections, locked/mutexed items) to a reasonable level. More threads working equals more threads blocking eachother and waiting for resources.

I hope that someone who has more experience in the area can give you better help, though, because their two cents will be worth much more than mine.
 
okay. i'll stick with a fixed number of threads.
Caqs the webrequests are really time consuming. when using one thread i can finish 30 operations per minute. when using four threads the program is able to finish more than one hundred operations.

the ideal program would determine the right number of threads dynamically by checking cpu and memory usage. but that's probably overkill to my little app.

thx anyway....
 
Yer, I failed to take into account something which was out of the control of the application, such as the lag from a http request. Oh well, it's not the first time and I'm sure it won't be the last.
 
Have you tried using the ThreadPool to allocate the threads for you - this does implement some internal mechanisms to regulate the number of threads spawned based on CPU usage.
 
Back
Top