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

>>>>> The rule of thumb is don't bother spawning more threads than you
>>>>> have cpus. You're just wasting resources mostly.
>>>>>
>>>> You REALLY don't want more threads trying to run than you have cores.
>>>> Threads in a wait state, are less of an issue, but they still use up
>>>> resources.

>
> Personally I'd never use more threads than cores as a program design,
> but I'm a performance whore. ;)
>

Could you explain why you believe this a bit more?  I'm curious because I've worked with databases and the rule of thumb there was you should configure them to use twice as many threads as number of cores/CPUs. The reasoning, I believe, is that if one thread on the CPU is stalled, another thread can execute in it's place.  And yes, I believe this was before hyperthreading.

Though I wasn't informed of the specifics as to why, I'm guessing it's mainly because with a database, there's a good chance you have to perform some sort of disk I/O.  Therefore instead of having the CPU wait while the I/O is occurring, another thread can start executing while the original is waiting.

Casey

On Mon, 12 Jul 2010 00:03:53 +0200, BLS <windevguy@hotmail.de> wrote:
> 
> On 11/07/2010 21:29, Philippe Sigaud wrote:
> > I tried this because I was reading an article on Scala's actors, where they talk about millions of actors. I guess they are quite different.
> 
> Google for fibers or have a look at the dreactor project on dsource.
> Tango has fiber support (afaik).
> 
> hth bjoern

Phobos2 has a Fiber class in core.thread as well.

On 12/07/2010 10:35, Justin Spahr-Summers wrote:
> On Mon, 12 Jul 2010 00:03:53 +0200, BLS<windevguy@hotmail.de>  wrote:
>>
>> On 11/07/2010 21:29, Philippe Sigaud wrote:
>>> I tried this because I was reading an article on Scala's actors, where
>>> they talk about millions of actors. I guess they are quite different.
>>
>> Google for fibers or have a look at the dreactor project on dsource.
>> Tango has fiber support (afaik).
>>
>> hth bjoern
>
> Phobos2 has a Fiber class in core.thread as well.

Thanks Justin,
just wish that core. documents are comparable to the std. ones. (At least)
Beside.. why core is not documented at all ?
bjoern

On Mon, 12 Jul 2010 13:56:53 +0200, BLS wrote:

> On 12/07/2010 10:35, Justin Spahr-Summers wrote:
>> On Mon, 12 Jul 2010 00:03:53 +0200, BLS<windevguy@hotmail.de>  wrote:
>>>
>>> On 11/07/2010 21:29, Philippe Sigaud wrote:
>>>> I tried this because I was reading an article on Scala's actors, where they talk about millions of actors. I guess they are quite different.
>>>
>>> Google for fibers or have a look at the dreactor project on dsource.
>>> Tango has fiber support (afaik).
>>>
>>> hth bjoern
>>
>> Phobos2 has a Fiber class in core.thread as well.
> 
> Thanks Justin,
> just wish that core. documents are comparable to the std. ones. (At
> least) Beside.. why core is not documented at all ? bjoern


I'm pretty sure they will be soon, perhaps even in the next release:

http://www.dsource.org/projects/druntime/changeset/321

-Lars

On 12/07/2010 14:18, Lars T. Kyllingstad wrote:
> I'm pretty sure they will be soon, perhaps even in the next release:
>
> http://www.dsource.org/projects/druntime/changeset/321
>
> -Lars

Thanks Lars.. Good news ! Hope the auto x = whatever(); //  thing for ddoc is also solved than..

On 12/07/2010 02:50, sybrandy wrote:
>>>>>> The rule of thumb is don't bother spawning more threads than you
>>>>>> have cpus. You're just wasting resources mostly.
>>>>>>
>>>>> You REALLY don't want more threads trying to run than you have cores.
>>>>> Threads in a wait state, are less of an issue, but they still use up
>>>>> resources.
>
>>
>> Personally I'd never use more threads than cores as a program design,
>> but I'm a performance whore. ;)
>>
>
> Could you explain why you believe this a bit more? I'm curious because
> I've worked with databases and the rule of thumb there was you should
> configure them to use twice as many threads as number of cores/CPUs. The
> reasoning, I believe, is that if one thread on the CPU is stalled,
> another thread can execute in it's place. And yes, I believe this was
> before hyperthreading.
>
> Though I wasn't informed of the specifics as to why, I'm guessing it's
> mainly because with a database, there's a good chance you have to
> perform some sort of disk I/O. Therefore instead of having the CPU wait
> while the I/O is occurring, another thread can start executing while the
> original is waiting.
>
> Casey

I'd expect databases to have quite odd performance characteristics compared to a more normal application though; You'd expect them to be IO bound most of the time, so having more threads than cores sounds like a reasonable thing to do.

If you aren't waiting on the disc, then more threads aren't going to help, they'll just be contending for cpu time as BCS said.

Still that's one of the drawbacks with multi threading, there's really not many absolute statements you can make or things you can assume.

You'll have to profile you application and fiddle with it to find out how to get the best performance out of it.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

> I'd expect databases to have quite odd performance characteristics
> compared to a more normal application though; You'd expect them to be IO
> bound most of the time, so having more threads than cores sounds like a
> reasonable thing to do.
>
> If you aren't waiting on the disc, then more threads aren't going to
> help, they'll just be contending for cpu time as BCS said.
>
> Still that's one of the drawbacks with multi threading, there's really
> not many absolute statements you can make or things you can assume.
>
> You'll have to profile you application and fiddle with it to find out
> how to get the best performance out of it.
>

Yeah, that was my assumption.  It just sounded like there was more to it.

Thanks.

Casey