4 ms·
Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. Using nonblocking IO will provide better performance
by openasocket 11y ago
Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve. It's not a silver bullet, and can be very difficult to implement at the application layer to avoid blocking, but it will give markedly better performance.
- TheHydroImpulse 11y agoBut one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model. So you're not forced to store all the thread's stacks and you don't have expensive context switches. As the parent illustrated, even with Go using nonblocking I/O, it's perceived benefits in that area isn't that great because Go still semantically has a thread-per-connection. So the performance characteristics of Go isn't simply async vs sync I/O.
- openasocket 11y ago>But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model. One reason, not the only, or the most important. The primary advantage of non blocking IO is that the CPU isn't sitting idle while waiting for an IO operation to complete. We aren't wasting an entire core to write the response.
- pcwalton 11y agoThat's not how blocking I/O works! Sitting in a busy loop on the CPU burning power polling the I/O device was, like, how the Apple II may have worked, but it hasn't worked like that on any major OS since at least 1990. Operating systems perform context switches on I/O.
- pcwalton 11y ago> Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. I know, of course. If you reread my comment, you'll notice that it wasn't focusing on the particular syscall that the system uses. > Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve. Because of (a), (b), and/or (c), which I addressed in my comment above.
- openasocket 11y agoRight, so Hyper would be faster if it used true asynchronous I/O, right? That was my whole point. I just brought up Go so I had something to compare it to.
- f2f 11y agoHyper may very well be much faster, but it isn't. Which is the whole issue with the Rust vs Go debates: one is possibly much better, but the other one gets all the code written for it in 1/6th of the time (Rust came out the same time Go did, to great fanfare). Are we willing to wait 6x longer for rust to catch up? Some people are, most people aren't.
- pcwalton 11y agoI don't know whether you're talking about a 6x development speed differential or a 6x performance difference between Rust and Go HTTP stacks or what, but I am pretty sure that by making up numbers like that you're language warring for no reason.
- f2f 11y agoyes, in this case i am language warring for no reason. i'm an unapologetic go devotee but i like rust just the same. i wish people would just get on with things and write software, rather than comment on minutiae on message boards.