🚀 go-pugleaf

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote in message
news:3e6fc46e$1@newsgroups.borland.com...
>
> "Dennis Jones" <djones@nospam.com> wrote in message
> news:3e6fb851$1@newsgroups.borland.com...
> > 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 can only speak for my own software in that regard, but I don't see that
> happening.  In my company's primary software, the one running 100s of
> threads at a time, the majority of them are actively processing live data
> through the lifetime of each thread from start to stop without much in the
> way of noticable performance hits.

Are you saying that the program experiences no degredation in performance
due to those 100's of context switches, or that the program is not
significantly impaired by 100's of context switches?  Saying that the
program still performs well, or within expected limits, or even that you
don't notice any degredation in performance, doesn't necessarily mean that
it isn't happening.  However, you certainly can't complain too much about it
if the program still performs well!

You probably have a case where fewer threads might be more efficient from
the OS'es perspective (because of context switching), but would be
unacceptable from the application's perspective (because the application is
expected to, or required to, perform those 100's of operations
simultaneously).

Is it possible for your application to operate with fewer threads (say, 4 or
5)?  I would be curious to see the results of measurements where the
application runs with significantly fewer threads, and then again with
significantly more threads (where both cases perform the same amount of
work).

- Dennis