std.concurrency, speed, etc.

[Adam Conner-Sax]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> Adam Conner-Sax Wrote:
> >
> > 1) I couldn't get the synchronized class version (as opposed to using
> > synchronized statements in the functions) to run.  It would hang in odd ways.
> >  This may be related to a bug I reported earlier (and Sean was helpful enough
> > to fix!) so this may be moot.
> 'synchronized' as a class label may not be implemented in the compiler yet.  I'd
stick to explicitly labeling methods are 'synchronized' for now.

I couldn't get that to work either.  What does work is a "synchronized" block of
code.  That seems potentially more efficient also.

> > 2) Message passing is slow in my tests.  Often an order of magnitude or more
> > slower than the fastest (lock-free queue).  I expect to pay some price for the
> > convenience, etc. but that seems excessive.
> The limiting factor at this point is the cost of copying the Message struct
around during processing.  I've eliminated nearly all copies by passing by ref
internally, but I believe an unnecessary copy or two may still remain.  I'll see
about tuning this further.  Tuning the ctor and copy ops in Variant and Tuple
would help as well, since nearly all the time spent is in those routines.  For
what it's worth, it's fairly easy to time this by building with -profile and
having the main thread send messages to itself (since -profile doesn't yet work in
multithreaded apps).

Right.  I've run into the multithreaded profiling issue.  What you're describing
makes sense: message passing has a much higher minimum time (7-8 us) than any of
the others (1-2 us).  That could be copying.  I had thought it was some sort of
wakeup to the receiver.  The other methods just have a while loop waiting on new
data rather than the blocking "receive" so I imagined there was some cost to
waking up the receive thread.
> > 4) I still don't totally understand shared.  It does what I expect when
> > variables are static.  That's why all the queues are static objects.  But that
> > doesn't scale so well (I know I could set up static factories for static
> > objects but that seems like it shouldn't be necessary).  When I put an
> > unshared variable in a non-static class and then use the class from multiple
> > threads, the variable acts shared.  Is that a bug or a feature?
> Maybe you're just lucky?  It's hard to reason about behavior without an example.

Maybe.  I'd rather it not work this way (sharing even though not marked shared).
Then I could put the queues into non-static structures and get the shared and TLS
the way I expect.  That would make using them from a spawned function a bit
trickier but I think that could be handled.

Thanks for the thoughts.

Adam