Comment 1:

Per the mailing list thread on this, the issue is that Go is TCP_NODELAY by default,
where your C++ client has Nagel on by default.

Status changed to Invalid.

Comment 2:

If you use DialTCP instead of Dial, you will get a TCPConn, and then you can call
SetNoDelay(false).

Comment 3 by steve.wangbin:

The go client is still 3x slower even though NoDelay is false.
====
$ time ./client_go
real    0m10.202s
user    0m3.808s
sys 0m6.368s
$ time ./client_cpp
real    0m3.366s
user    0m0.220s
sys 0m3.132s

Comment 4 by steve.wangbin:

And the server still have to invoke function recv() much more times.
for cpp client:
$ ./server_cpp
recv system call times: 986183
recv bytes: 20000000
for go client:
$ ./server_cpp
recv system call times: 4951222
recv bytes: 20000000

Comment 5:

Attach a pcap file (from e.g. tcpdump or wireshark) & strace -f output of the Go binary.

Labels changed: removed priority-triage.

Status changed to WaitingForReply.

Comment 6 by vladislav.chugunov:

strace -f shows
[pid 30088] write(3, "ab", 2 <unfinished ...>
[pid 30087] <... select resumed> )      = 0 (Timeout)
[pid 30088] <... write resumed> )       = 2
[pid 30087] select(0, NULL, NULL, NULL, {0, 10000} <unfinished ...>
after every random small amount(70 - 120 on my laptop) of 
[pid 30088] write(3, "ab", 2)           = 2

Comment 7 by steve.wangbin:

The files got from tcpdump and strace are too large to upload because of the maximum
size of attachment.
So I upload the revised files with NoDelay being false.
I believe this issue is quite easy to reproduce.
There is one thing I have not mentioned is that I just ran these programs on
localhost(127.0.0.1), and I'm not sure whether it matters.

Attachments:

1. client.cpp (797 bytes)
2. client.go (525 bytes)
3. server.cpp (765 bytes)

Comment 8 by steve.wangbin:

Here is strace.txt.tar.gz.
The file created by tcpdump is too big to attach.

Attachments:

1. strace.txt.tar.gz (74479 bytes)

Comment 9:

I can't reproduce on darwin/amd64.
dtraces:
https://gist.github.com/kylelemons/5719397
The only thing that happens is that as you disable nodelay and switch to C, a higher
proportion of the server's writes are fast enough to be read by the same read syscall. 
It doesn't take much in such a tight loop to balloon the run time, so the difference
between the C and Go version (+17%) and between the nagle and nodelay version (+25%)
doesn't seem extraordinary, especially since in any real program the delay between
writes will be dominated by other processing time (and writes won't be two-bytes
each...).

Comment 10:

I'm not sure there's much to do here. Go has the overhead of the select loop and such,
but those can't be removed.

Comment 11:

Status changed to Unfortunate.