More threads = better program? I don't think so.

[Insider1984]

We have a in house data processing program (image processing to be exact). We are running them on Dual 2.0Ghz G4 on one machine. One of our programs swears that having it setup for 8 threads (the number of independant image acq. boards) is better than setting up for 2 or 4.

I see his side in one view but since acq is hardware controlled (not affected by cpu usage) would it be better to match the threads to the processors we have available?

Is there some rule I can look to in the future for this?

I always thought you want to use multiple threads to increase the fluidity(is that a word) of your applications (aka gui and core use different threads). In this case we are purely cranking data through the processsors. a thread match to the processors seems to make sense although I havn't taken any offical classes on the subject.

Please advise.
PS> my subject would make you believe I don't believe in threaded applications. That is wrong... I just am wwondering if in a purely data processing app. if having 4 times the threads as you do processors is a healthy habbit?

Thanks again.

=====================
Insider
4 year 'on the fly' programmer
C++ Basic Java

 

[PerFnurt]

It seems like the program suggests you have 1 thread per acq board, and I assume there's a point if the data gathering should be evenly distributed over the boards and performed simultaneously.

Not that windows is a realtime operating system anyway...





/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[Cagliostro]

you will create thread only when you need it.
For example, you send something to print:
1. You create another thread, create a information to print in the new thread and send it. This will not stop your program until printing.
2. You have a TCP server which has more clients, for example a chat. You will create a separated thread for each client on the server side.
3. All other multiclient/server applications.

In any other cases you have just few reasons to create new threads. Usualy you do not need multithreading.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[Insider1984]

IonFilipski so you are saying I should keep it 2 threads 1 for each processor?

PerFnurt yes currently one processing thread per camera is what we run. The problem I have is that it's a feed type system that means acq board 1-8 doesn't get to move on to the next acq until all the data is processed from each of the 1-8 cameras.

I would fully understand 8 threads if the boards weren't acqed in sequence but really we are just processing the sh*t of the data. pumping it through on 2 threads would be better.

=====================
Insider
4 year 'on the fly' programmer
C++ Basic Java

 

[PerFnurt]

> I would fully understand 8 threads if the boards weren't acqed in sequence

I agree. How about you just try it out with all the threads and check how performance is affected (if at all).



/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[PerFnurt]

ahem.. that is
&quot;it out without all the threads&quot;

/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[palbano]

Logically it seems that the application runs on a CPU processor not one of the image boards. Therefore only as many threads can be executing as there are processors, period.

That does not however mean that matching the CPU’s in number of threads is the most efficient approach to the application design. If you really want to answer this question you need to profile separate instances of the application in it’s various configurations of “threads to processors”.


-pete

 

[Cagliostro]

If you have a conceptually &quot;one single thread application&quot;, creating of many threads on many processors will not means at all a more efficient application. For best efficiency you should create only as many threads as you need.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[JOLESEN]

Starting a new thread should be done when it makes sense to do so (design- and performance-considerations).

Have a look in taskmanager / processes (You may have to add thread-count to current view) :

On my single cpu machine running XP, some processes have more than 70 threads.

I don't think you can have a rule of thumb here.

/JOlesen

 

[VincentP]

Did you say that the 8 feeds must be read sequentially? Then it seems to me that even two threads is not going to improve anything, since the second thread will have to wait for the first one to finish before it starts. You would need a way to split the data processing of one camera into two parallel threads to use your dual processor fully.

Vincent

 

[Insider1984]

VincentP

No not exactly. I can't go into all the details here but:

8 acq boards in a line. They don't need to fire in any order but do need to all fire before they can fire again.

THis is already a separate thread.

Then we have a data processing thread that does just that. It's currently setup for 8 threads. I plan to setup for 2 since it's the &quot;worker thread&quot; and by the looks of acticles and past history your workers threads( the threads that need the most CPU cycles) should be equal your processors (each processor takes a thread).

This doesn't mean that I don't have 10 other threads running casually in the background polling or printing data to files (I do) but spliting the threads into 8 seems like a waste of resources better spent on cranking on 2 threads.

=====================
Insider
4 year 'on the fly' programmer
C++ Basic Java