On 8/17/21 2:36 PM, JG wrote:
Thanks for the suggestions and explanations. I am not sure what to do in
my case though. The situation is as follows. I have a struct that is
populated via user input not necessarily at single instance (so that
seems to rule out immutable). On the other
hand while
On 8/17/21 11:36 AM, JG wrote:
>>> Maybe message parsing isn't the
>>> correct solution?
I use message passing in many of my programs.
> After being populated it should be passed to
> the other thread and no references are kept.
Then you simply cast to-and-from 'shared' and be happy with it. :
On Tuesday, 17 August 2021 at 12:24:14 UTC, Steven Schveighoffer
wrote:
On 8/17/21 7:05 AM, JG wrote:
Hi
I have a program with two threads. One thread produces data
that is put in a queue
and then consumed by the other thread. I initially built a
custom queue to do this, but thought this shou
On 8/17/21 7:05 AM, JG wrote:
Hi
I have a program with two threads. One thread produces data that is put
in a queue
and then consumed by the other thread. I initially built a custom queue
to do this, but thought this should have some standard solution in D? I
looked at std.concurrency and tho
On Tuesday, 17 August 2021 at 11:05:09 UTC, JG wrote:
Hi
I have a program with two threads. One thread produces data
that is put in a queue
and then consumed by the other thread. I initially built a
custom queue to do this, but thought this should have some
standard solution in D? I looked at
Hi
I have a program with two threads. One thread produces data that
is put in a queue
and then consumed by the other thread. I initially built a custom
queue to do this, but thought this should have some standard
solution in D? I looked at std.concurrency and thought that
message passing coul
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 g
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
resou
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 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 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
On 12/07/2010 10:35, Justin Spahr-Summers wrote:
On Mon, 12 Jul 2010 00:03:53 +0200, BLS 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
On Mon, 12 Jul 2010 00:03:53 +0200, BLS 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
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 mor
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 dep
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 bjo
On 11/07/2010 21:43, BCS wrote:
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
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, but
On 11/07/2010 20:29, Philippe Sigaud wrote:
On Sun, Jul 11, 2010 at 20:00, div0 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?
I thought it'd be on
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 us
On Sun, Jul 11, 2010 at 20:00, div0 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 2nd cpu is
> co
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.
--
... <
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
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.
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 that be different if each t
Hi,
so, after reading TPDL, I decided to test my comprehension of message-passing
and such. Please note that before this day, I never wrote any concurrent code,
ever.
I wanted to begin with a simple problem: summing all numbers in a range. So I
used the following code:
import std.concurrency, st
24 matches
Mail list logo
