Improving the critical path

[cda-group]

Improving the critical path

[Bathtor]

The most common channel strategy is a forward one, that is, one-to-one.

I don't think this will be true. Most of the code with this pattern should be fused by the compiler. The most common actual channel implementation should be multiple many-to-one channels, which are encountered during partitioning. So I don't think it's worth optimising for this.

Fixed sized queues are probably a good idea, but we need to integrate that with Adam's work on backpressure, because it would introduce a hard limit on outstanding jobs, the violation of which would cause runtime failures. The SeqQueues may do some allocation, but once they are warmed up and driven at similar load for a while, they usually perform very well...and they do respond to changing load levels, as opposed to ArrayQueues, where you need to pre-allocate for the the worst-case load level in advance.

in the end, in a distributed system usually network traffic will be the bottleneck, not local queues, so prematurely optimising for it is probably not a good way to spend our time.

I do think NUMA aware place is valuable, though. For many jobs this will kind of happen automatically the way that my scheduler is designed, but if we know a fairly static layout a-priori, we could optimise and do slightly more static assignments from the start.

[Max-Meldrum]

elements are batched now. NUMA can be looked at through another issue in the future.