On Mon, 12 Jul 2010 00:03:53 +0200, BLS windev...@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
On 12/07/2010 10:35, Justin Spahr-Summers wrote:
On Mon, 12 Jul 2010 00:03:53 +0200, BLSwindev...@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
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
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
Philippe Sigaud philippe.sig...@gmail.com wrote:
- Why is a 2 threads version repeatedly thrice as fast as a no thread
version?
I thought it'd be only twice as fast.
No idea.
- 1024 threads are OK, but I cannot reach 2048. Why? What is the limit
for the
number of spawn I can do? Would
On 11/07/2010 15:28, Philippe Sigaud wrote:
- Why is a 2 threads version repeatedly thrice as fast as a no thread version?
I thought it'd be only twice as fast.
Well if you are running on windows, my guess is that your 2nd cpu is
completely free of tasks, so the thread running on that one is
Hello div0,
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.
--
... IXOYE
On Sun, Jul 11, 2010 at 20:00, div0 d...@users.sourceforge.net wrote:
On 11/07/2010 15:28, Philippe Sigaud wrote:
- Why is a 2 threads version repeatedly thrice as fast as a no thread
version?
I thought it'd be only twice as fast.
Well if you are running on windows, my guess is that your
On 11/07/2010 20:00, BCS wrote:
Hello div0,
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
On 11/07/2010 20:29, Philippe Sigaud wrote:
On Sun, Jul 11, 2010 at 20:00, div0 d...@users.sourceforge.net
mailto:d...@users.sourceforge.net wrote:
On 11/07/2010 15:28, Philippe Sigaud wrote:
- Why is a 2 threads version repeatedly thrice as fast as a no
thread version?
Hello div0,
On 11/07/2010 20:00, BCS wrote:
Hello div0,
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,
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
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
14 matches
Mail list logo
