Your answers are very decent, it solve all my doubts. Thank you very much! I believe I need to spend some time reading how runtime scheduler works for more deep understanding of all "magic".
Cheers, changkun On Monday, September 17, 2018 at 9:25:20 PM UTC+2, Ian Lance Taylor wrote: > > On Mon, Sep 17, 2018 at 12:17 PM, changkun <euryu...@gmail.com > <javascript:>> wrote: > > > > Those overhead you mentioned come from goroutine scheduler for entering > a > > system call. > > Apparently, there is no such mechanism in Go to submit an IO > "transaction" > > if there are two > > or more syscall close to each other, syscall can be held in OS thread > > without exit back to goroutine > > and save redundant bookkeeping, isn't? > > That is correct: there is no such mechanism in Go. > > > > Then, what about the net package? Socket pair FDs are pollable thus can > > converted to net.Conn. > > What happened to them and why it's performance even much "worse" than > pure > > syscall and close to > > Cgo calls? Is the benchmark measured in a wrong way? Are all I/Os call > via > > net package suffering it? > > The net package is quite different from direct syscalls. The net > package is optimized for handling intermittent I/O on many thousands > of different descriptors. The net package uses a runtime poller so > that each separate descriptor does not require its own dedicated > thread. That introduces more bookkeeping and more overhead. It's the > right choice for an HTTP server but will not be the best choice for > the highest possible I/O throughput on a single descriptor. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
