On 12/21/12 12:17 AM, Brian Anderson wrote:
In the best case you essentially just want to be able to quickly
transfer large buffers from the client task to the I/O task, or the
other way. In a dual-core setup pipes should be able to do that very
fast, rarely yielding to the (Rust) scheduler.
Well, my point is that in *this* benchmark we will still lose. The
benchmark that Michael wrote waits on the results of each Redis query
before sending the next one. This makes the main thread always fall
asleep, so every pipe send will have to fall into the scheduler to punt
the main thread awake. It's basically the worst case for our setup.
I suspect the performance of this benchmark would be better if:
(1) The code were written in a more asynchronous "fire-and-forget" style
rather than waiting on the results of each query before sending the next
one; and/or:
(2) There were large (like, 100,000+) numbers of tasks involved, so that
the performance advantages of M:N threading over 1:1 threading start to
kick in.
But, as written, this benchmark is fundamentally better served by 1:1
blocking APIs.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
