std.parallelism: Final review

[dsimcha]

On 3/18/2011 7:33 PM, Jonas Drewsen wrote:
>> Not in Cilk style. Everything just goes to a shared queue. In theory
>> this could
>> be a bottleneck in the micro parallelism case. However, some
>> experimentation I
>> did early in the design convinced me that in practice there's so much
>> other
>> overhead involved in moving work from one processor to another (cache
>> misses,
>> needing to wake up a thread, etc.) that, in cases where a shared queue
>> might be a
>> bottleneck, the parallelism is probably too fine-grained anyhow.
>
> I guess that work stealing could be implemented without changing the
> current interface if evidence shows up that would favor work stealing?

Yes, this would be possible.  However, in my experience super 
fine-grained parallelism is almost never needed to take full advantage 
of whatever hardware you're running on.  Therefore, I'm hesitant to add 
complexity to std.parallelism to support super fine-grained parallelism, 
at least without strong justification in terms of real-world use cases. 
  The one thing work stealing (and improvements to the queue in general) 
has going for it is that it would only make the implementation more 
complex, not the interface.