Multiplexing rust server

[jonhoo]

This branch introduces a single multiplexing Rust server based on #19 and #20 that operates as follows: With n cores, 2n threads are spawned:

• The first n iterate over all of their streams (explained below), calling iterate() on each one in turn. iterate() performs a single n -> n+1 iteration for a single client. These threads also listen on a per-thread mpsc channel for new streams that they adopt upon receipt.
• The second n cores accept new connections in a loop, and feed them to the first n threads in round-robin order. Before relinquishing a stream, they set TCP_NODELAY, and perform a single iterate() call on the stream. This is to comply with the client waiting for all connections to be operational before starting the benchmark.

Benchmark results will be posted shortly.

[jonhoo]

As the number of clients goes up, this outperforms the one-thread-per-client approach. I expect this trend to be even more visible with a larger number of clients.. Benchmarking that next.

[jonhoo]

Plot above updated to reflect changes in 6bc0a1a783c50fd1d13a463282784caa53b316c4

[jonhoo]

Interestingly, rust-multiplexperforms better than rust for a smaller number of cores, but on a larger number of cores, rust outperforms (and scales past) rust-multiplex...

[xekoukou]

Could you also give data on the worker pool? (channeled-based thread worker pool)

I believe it will be twice as fast.

[jonhoo]

@xekoukou no, rust-multiplex is always faster, and has significantly lower variance in latency.

[xekoukou]

Probably, it was due to my 2-core laptop that i saw the difference.

By the way, a variance in latency is not a variance in the mean ops per second. The mean ops per second is quite stable.

[jonhoo]

Variance should translate exactly to variance in ops per second (though admittedly not to mean ops per second), as ops/s = 1/(s/op).