Grokking concurrency, message passing and Co

[BCS]

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><