go-blocking: Increase threads for connections

[jonhoo]

I'll run a benchmark with this patch later today, as well as one without LockOSThread as suggested by @diegobernardes. I'll also try one with GOMAXPROCS(201) to see what kind of overhead increasing GOMAXPROCS on the fly has.

[jonhoo]

It's hard to say which approach is better. Incrementing GOMAXPROCS on the fly seems like it provides some performance boost, but given that the hardcoded value of 201 is too high when the number of clients is less than 200, this might be misleading. LockOSThread appears to help performance somewhat, but its performance also drops when the number of cores grows large. I'm not entirely sure why this happens.

[diegobernardes]

Nice to see two things in the chart:

• With incthreads and fixthreads the latency has been reduced drastically
• The speedup curve is better with lock

So golang now has more or less the same performance as rust without the multiplex, lets see how golang-multiplex performs.

The real test gonna happen when someone implement rust with mio.

---

I asked in gonuts group about the change of GOMAXPROCS during runtime and Dave Cheney answered this:

It will be both. Goroutines that return to the scheduler will find that their hosting thread is surplus to requirements and they will be reassigned to another threads work pool. However, work in progress will not be affected until those goroutines block on a syscall or channel send/ receive.

I really don't know if this can impact or not the performance :disappointed:

[jonhoo]

I'm pretty sure dynamically increasing GOMAXPROCS shouldn't make much of a difference. Decreasing might carry a performance penalty, but we're not doing that here.

Good catch about the latency. You're right, this seems to have helped significantly, though that is probably just because more threads can now block simultaneously. I'm still concerned that the right-hand side of the performance curve flattens with this change though, whereas the fixed-thread implementation does not.

I'm waiting on a response from @methane before I can test #23, but yes, it will be interesting to see. I'm not quite as convinced it is a reasonable design though, as it is essentially a less flexible implementation of multiplexing (just like rust-multiplex).

[jonhoo]

@diegobernardes: my guess is that this was added to amortize the cost (if any) of incrementing GOMAXPROCS. Since it is double each time, we will only have to do log n increments instead of n for n clients.