Hello div0,
On 11/07/2010 21:43, BCS wrote:
In what way?
Sometimes it just makes your program design easier if you fork a
process / spawn a thread; than trying to manage a thread pool and
allocating work to a fixed number of threads. Programmer time is more
expensive than cpu time and it depends who's paying the bill.
Ah, yes. I agree with that. But then, in most of the cases I can think of
where that's a good idea, the forked thread spends most of it's time waiting
and thus contributes a almost nothing (or very rarely, depending on how you
look at it) to the number of threads trying to run.
(hmm, haven't you said that before?)
Actually, I've argued almost the reverse. The end users time is very valuable,
his CPU's only slightly less so, the programers time much less so, and his
build farm's time is practically free. But then you have to keep in mind
the 80/20 rule, premature optimization, and all that stuff.
My thinking is along the lines of: if a programmer can, in 10 minutes, save
every user 1 second a day, then you only need 5 users using the program for
6 months to recoup his time in full. And if you don't have even that many
users, go work on something that does!
And In re-reading my post, I noticed it can be read it two ways. The
way I intended it, is as a "yes and" statement: while often there is
little to be gained by having more threads than cpus/cores, there is
almost always nothing to be gained by having more thread trying to do
stuff at the same time than you have cpus/cores to run them on.
Personally I'd never use more threads than cores as a program design,
but I'm a performance whore. ;)
--
... <IXOYE><
