Closed diegobernardes closed 9 years ago
Hmm, no, I don't think I want to accept this. It is effectively cheating -- servers generally do not know how many clients there might be.
Ok, no problem, but the golang test gonna always perform worse than c and rust because we running with less threads.
If there was a way of doing this without passing in the number of clients, I'd be fine with it. Like incrementing GOMAXPROCS
for every new client or something. I'm not sure that'd be a good idea though :confused:
How about runtime.GOMAXPROCS(runtime.NumCPU() * 4)
?
It didn't matter much for the idiomatic Go implementation (#2), but I can run some benchmarks on go-blocking
with a higher GOMAXPROCS
to verify. Do you think LockOSThread
is still necessary?
I don't know how much LockOSThread
increase (or decrease) performance.
I'll update go-blocking with "dedicated thread for each connection" model.
@diegobernardes Could you review #24 ?
@methane me review your code? who am i to do this, you that need to review my code.. :sweat_smile:
LockOSThread
didn't show any increase/decrease of performance on my notebook, and i don't have a 80 core machine to do the benchmark.
About the increase/decrease of GOMAXPROCS
during runtime, i don't know if this can decrease performance. Reading the method source code show calls to starttheworld
and stoptheworld
. Didn't found the declaration in go1.4, i think that this is done in c, but in tip is in golang
I dont have much time now to do deep analysis, but im afraid that we gonna have a extra overhead in this calls.
@jonhoo i don't know if you have time to do this or patience, but you could run the tests with the PR @methane submited and then we can do other rounds of tests without LockOSThread
and dynamic GOMAXPROCS(could set the gomaxprocs to always be 200, the max number of clients connected).
Continued in #24.
Now go-blocking has a new flag that receives the number of connections to create one system thread for each connection.