On Mon, Sep 17, 2018 at 1:41 AM, changkun <euryugas...@gmail.com> wrote: > > Thus, my first question is: Considering the scheduling strategy of goroutines > in Go universe, will the Go universe IO performance between a user socket and > socketpair[0] get suffering by such a blocking CGO call?
No. > The second question set is regarding IO performance. > > My benchmark shows the pure Go syscall Write and Read is roughly 15% slower > than C system call, and net package IO performance is roughly equal to CGO > call performance, as shown as follows: > > Test in go 1.11; Machine: MacBook Pro 2014 Retina; Data: > https://docs.google.com/spreadsheets/d/1DwtZmP8fKKr3pOQWVJrD30DSOzv4_qB5KZvsd-DQ1KA/edit?usp=sharing > > > So, questions are, what did I do wrong regarding these benchmarks? I'm > currently using syscall.Write() and syscall.Read() approach in different > write/read goroutines, is there any way to achieve performance closer to C > system call (expect down to 5%) for such a long time network IO? For the pure Go program, this is most likely due to Go scheduler overhead. When your program enters a potentially blocking system call like Write or Read, the Go program has to note that the goroutine might block for an indefinite period of time. I would guess that that bookkeeping is what you are seeing. If you have a single-threaded program that does nothing other than read and write system calls, it's going to be hard for Go to match the same performance of C. When using cgo there is similar scheduler bookkeeping overhead; on average it's a tiny bit worse with cgo because cgo requires changing calling conventions. 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.
