Closed methane closed 9 years ago
go-multiplex vs rust-multiplex is a fair game. But wouldn't that mean that goroutines have lost,whichever the outcome, as you need to reuse a goroutine to have similar performance.
This doesn't run correctly on my machine. The client hangs forever (seemingly) after "priming with 25000 iterations across 40 clients". Have you tried running the benchmark yourself with a smaller number of cores to check that it works?
This doesn't run correctly on my machine. The client hangs forever (seemingly) after "priming with 25000 iterations across 40 clients". Have you tried running the benchmark yourself with a smaller number of cores to check that it works?
Yes. It runs when GOMAXPROCS=8 and client -c8. But I confirm it doesn't run with GOMAXPROCS=40 and client -c40. I'll dig it in tomorrow.
I see. Rust's mpsc::channel
is infinite queue but Go's channel is finite queue.
I've fixed problem.
The Makefile clean
target still says go
, not go-multiplex
.
As previously mentioned, I'm hesitant to merge this since rust-multiplex
is really just a placeholder for rust-mio
. You would probably not write your server application this way because, as someone (you?) pointed out, it's not clear that it's that all clients always have outstanding requests.
Thanks! I'll benchmark this on Monday. As you pointed out on golang-nuts, both of these servers are sort of cheating -- it is not realistic that every client will always have something to do, and so these servers would end up blocking unnecessarily in a real-world use-case. The reason I implemented it in Rust is that it is a half-way stop towards full async I/O (using mio); when I get a proper mio implementation, that will replace
rust-multiplex
entirely. For Go it makes less sense since the idiomatic solution is already using async I/O.