How many std.concurrency receivers?

[Charles Hixson]

On 10/11/2012 12:09 AM, thedeemon wrote:
> On Thursday, 11 October 2012 at 02:21:01 UTC, Charles Hixson wrote:
>> I haven't been able to get an idea of how many std.concurrency
>> receivers is reasonable.
>
> Currently in std.concurrency each "receiver" lives in its own OS thread,
> so they are very expensive, 4-10 is fine, 100 may be possible but
> expensive in terms of RAM and CPU cycles, 1000 is probably too much.

Hmmm...what I'm trying to build is basically a cross between a weighted 
directed graph and a neural net, with some features of each, but not 
much in common.  Very light-weight processes would be ideal.  The only 
communication should be via message-passing.  Each cell would spend most 
of it's time sitting on a count-down timer waiting to be rolled out to a 
database of inactive processes, but it needs to maintain local state 
(weights of links, activation level, etc.  nothing fancy.)

If I were doing this sequentially, I'd want to use structs for the 
cells, because class instances would be too heavy.  And I'd store them 
in a hash table keyed by cell-id#.

Unfortunately, I don't see any reasonable way of chunking the pieces, so 
that I can chunk them into 100 relatively independent sets.  Or even 
1000.  10,000 is probably about the right size for active-at-one-time 
cells.  And if it would handle that, std.concurrency seemed ideal.

Do you have any suggestions as to what would be a reasonable better 
choice?  (Outside of going back to sequential.)