Re: To thread or not to thread ?
Sergey P. Derevyago wrote:
Victor Bazarov wrote:
It still not really an independent "perspective". It's a combination
of the other two;
Yes, that's the point.
... And you just trimmed away the actual point. Right there after the
semicolon which you've left in I say <<and since at any point in time
it only provides N threads where N is hardware-dependent, it is
actually a variation of the "1">>.
We're not obliged to choose only one alternative. We can combine the
best
properties of two.
But you _do_ choose the "1" (in your terms). Don't you actually see
it yourself?
Peter Becker wrote:
====
There are two different perspectives on multi-threaded
programming. On is "distribute the workload optimally among the
available processors." That's when you want just as many threads as
processor cores. The other is "logically divide the process into tasks
that can be run concurrently." That's when you want as many threads as
appropriate, and are willing to put up with some thrashing and delays
when you have more threads than cores.
====
The fact that you subdivide your processing into M tasks is irrelevant
because right after that you "map" them into 'N' simultaneous threads
based on the available hardware. So, the number of actual threads
running is governed by the hardware.
THAT'S the point.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]