std.concurrency, speed, etc.

[Sean Kelly]

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.

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