🚀 go-pugleaf

"Michael Kelly" <mkelly00@netzero.net> wrote in message
news:hq9v6vkjgup69jju5tdj5ltp9s72su9vlq@4ax.com...
> On Wed, 12 Mar 2003 11:39:18 -0800, "Dennis Jones" <djones@nospam.com>
wrote:
>
> >I seem to recall
> >reading something once which talked about the optimum number of
simultaneous
> >threads per processor being somewhere around 3 or 4.  Less than that, and
> >you are wasting processor time (assuming the threads go to sleep once in
a
> >while); more than that, and your process actually begins to slow down (if
> >all of the threads are active at the same time) because of context
> >switching.
>
> I would tend to think this is old time info maybe valid
> on 286 machines or some other CPU with really
> clunky context switching(as in simulating rebooting
> the machine!)  4 threads/cpu?  Man! You couldn't
> even bring up the Windows desktop!
>
> I think a Pentium can handle a few more than
> that. :)

Of course, I'm not necessarily agreeing with, or advocating, such a severe
limitation.  I personally have applications that routinely use 10-20 (or
more) threads (although not all of them are necessarily active at any given
time).  And since I don't remember the source of the information I've
paraphrased, I can't say with any certainty whether it was written with any
particular processor in mind.  Although I'm pretty sure was written long
after the pentium processor was widely available.

It may very well be that you can have 100's or even 1000's of threads
operating siumultaneously and that it won't affect the performance of your
application.  But it really does depend on the what the threads are being
asked to do.  If they are spending the bulk of their time sitting around
waiting for something else to happen (semaphore, event, critical section,
etc), then certainly, you can have that many threads and never take a
performance hit because the OS will efficiently avoid switching into the
context of a thread that is waiting for an OS event.  On the other hand, if
every one of those threads is busy doing something (or worse, is in a tight
loop watching the state of a flag), then the amount of context switching
would probably be significantly measureable, and seriously affecting
performance.

I would be interested in seeing an analysis of performance gain vs. context
switching overhead using varying numbers of threads for a given application.
Of course the optimum number of threads will differ depending on the type of
application, the role of each thread, and whether the threads are usually
busy, or usually waiting, but I am quite sure there will be some point at
which adding more threads becomes counter-productive -- for any application

- Dennis