Re: To thread or not to thread ?
Carlos Moreno wrote:
JohnQ wrote:
Why have more threads than the number of processor cores?
I'm baffled by this question ...
The above question is exactly equivalent to "why would we want
multithreading?"
Not exactly. One of the reason some people (particularly in the
numeric processing community) want threads is precisely to
spread the work out across multiple CPU's, so that it can be
done in parallel. Having to break one loop into N smaller
loops, run them in separate threads, synchronize at the end and
merge the results is a lot of extra programmer work, and added
complexity, but if those N smaller loops run in parallel on
different CPU's, the results can be a lot, lot faster. (You
won't speed things up by a factor of N, because of the added
overhead of synchronization, but if N == 256, if done correctly,
you can often achieve a speed up of a factor of 200 or more.)
Of course, that's not the only reason people use multiple
threads.
If you have several things to do in the morning (like, right
after waking up and going to work), such as making coffee;
a process in which you turn on a switch, and your machine
does everything else --- albeit, taking three minutes before
it's finished; then, you just have to grab a cup/mug and pour
the coffee and drink it, turn on the TV to see the weather
forecast (or firing up your PC and connect to whatever dot
com you use for the weather), and then iron your shirt... Just
because you have a single body (single brain, single pair of
hands, etc.), would you force yourself to do those tasks
sequentially?? Would you refuse to go check the weather during
the three minutes that the coffee machine is taking to finish
your coffee?
Except that you don't necessarily need multi-threading for that.
The advantage with regards to multithreading involves state.
For multithreading to be useful in such cases, it is necessary
that 1) individual operations involve a number of "blocking"
operations---operations where the code is just waiting on
something else---, 2) that the operations involve
significant state, especially if that state controls the
workflow of the operation, and 3) that separate operations share
significant in-memory data. Without the first, you don't gain
anything (unless there are multiple cores) compared to just
executing the operations sequentially (although in certain
cases, especially if one thread had higher precedence, you might
gain in reactivity). Without the second, there's no reason not
to return to the main wait loop for each wait---GUI programs did
this for years. Without the third, you're probably better off
using separate processes, rather than threads.
Of course, other considerations can be involved. I already
mentionned the reactivity one: even if processing the last click
requires 10 or 20 seconds raw CPU, you want to be able to redraw
the window if it is covered and then uncovered. Robustness and
reliability also plays a role: sharing state between processes
is more complex (and slower) than sharing it between threads,
but if one process core dumps, the others go on working, and if
you are explicitly managing the state, returning to the main
loop for each wait, synchronization is much, much simpler, and
you don't have nearly as much risk of a deadlock or a race
condition.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]