Go和C都直接涉及系统调用(从技术上讲,C将调用存根)。
从技术上讲,写入既是系统调用又是C函数(至少在许多系统上)。但是,C函数只是一个调用系统调用的存根。 Go不会调用此存根,而是直接调用系统调用,这意味着C不在此处
我的基准测试显示,纯C系统调用比最新版本(go1.11)中的纯Go系统调用快15.82%。
我想念什么?可能是什么原因以及如何对其进行优化?
基准:
开始:
package main_test
import (
"syscall"
"testing"
)
func writeAll(fd int, buf []byte) error {
for len(buf) > 0 {
n, err := syscall.Write(fd, buf)
if n < 0 {
return err
}
buf = buf[n:]
}
return nil
}
func BenchmarkReadWriteGoCalls(b *testing.B) {
fds, _ := syscall.Socketpair(syscall.AF_UNIX, syscall.SOCK_STREAM, 0)
message := "hello, world!"
buffer := make([]byte, 13)
for i := 0; i < b.N; i++ {
writeAll(fds[0], []byte(message))
syscall.Read(fds[1], buffer)
}
}
C:
#include <time.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
int write_all(int fd, void* buffer, size_t length) {
while (length > 0) {
int written = write(fd, buffer, length);
if (written < 0)
return -1;
length -= written;
buffer += written;
}
return length;
}
int read_call(int fd, void *buffer, size_t length) {
return read(fd, buffer, length);
}
struct timespec timer_start(){
struct timespec start_time;
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start_time);
return start_time;
}
long timer_end(struct timespec start_time){
struct timespec end_time;
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &end_time);
long diffInNanos = (end_time.tv_sec - start_time.tv_sec) * (long)1e9 + (end_time.tv_nsec - start_time.tv_nsec);
return diffInNanos;
}
int main() {
int i = 0;
int N = 500000;
int fds[2];
char message[14] = "hello, world!\0";
char buffer[14] = {0};
socketpair(AF_UNIX, SOCK_STREAM, 0, fds);
struct timespec vartime = timer_start();
for(i = 0; i < N; i++) {
write_all(fds[0], message, sizeof(message));
read_call(fds[1], buffer, 14);
}
long time_elapsed_nanos = timer_end(vartime);
printf("BenchmarkReadWritePureCCalls\t%d\t%.2ld ns/op\n", N, time_elapsed_nanos/N);
}
340个不同的运行,每个C运行包含500000个执行,每个Go运行包含b.N个执行(主要是500000,在1000000次中执行了几次):
2个独立平均值的T检验:t值为-22.45426。 p值<.00001。结果在p <.05时很明显。
2个从属均值的T检验计算器:t的值为15.902782。 p的值<0.00001。结果在p≤0.05时很明显。
更新:我在答案中管理了提案,并编写了另一个基准测试,它表明所提出的方法大大降低了大规模I / O调用的性能,其性能接近CGO调用。
基准:
func BenchmarkReadWriteNetCalls(b *testing.B) {
cs, _ := socketpair()
message := "hello, world!"
buffer := make([]byte, 13)
for i := 0; i < b.N; i++ {
cs[0].Write([]byte(message))
cs[1].Read(buffer)
}
}
func socketpair() (conns [2]net.Conn, err error) {
fds, err := syscall.Socketpair(syscall.AF_LOCAL, syscall.SOCK_STREAM, 0)
if err != nil {
return
}
conns[0], err = fdToFileConn(fds[0])
if err != nil {
return
}
conns[1], err = fdToFileConn(fds[1])
if err != nil {
conns[0].Close()
return
}
return
}
func fdToFileConn(fd int) (net.Conn, error) {
f := os.NewFile(uintptr(fd), "")
defer f.Close()
return net.FileConn(f)
}
上图显示,有100种不同的运行,每个C运行包含500000次执行,每个Go运行包含b.N次执行(主要是500000,在1000000次中执行了几次)
答案 0 :(得分:14)
我的基准测试显示,纯C系统调用比最新版本(go1.11)中的纯Go系统调用快15.82%。
我想念什么?可能是什么原因以及如何对其进行优化?
原因是,虽然C和Go(在Go支持的典型平台上,例如Linux或* BSD或Windows)都被编译为机器代码,但是Go-native代码在与C完全不同的环境中运行
与C的两个主要区别是:
因此,当Go代码想要进行系统调用时,应该发生很多事情:
P
是在OS线程上运行goroutine的东西)。更新回答OP的评论
<...>因此,没有办法进行优化,我必须忍受如果进行大量IO调用,对吗?
这在很大程度上取决于您所追求的“大规模I / O”的性质。
如果您的示例(带有socketpair(2)
)不是玩具,则完全没有理由直接使用系统调用:socketpair(2)
返回的FD是“可轮询的”,因此Go运行时可以使用其本机代码“ netpoller”机器以对其执行I / O。这是我的一个项目中的工作代码,可以正确地“包装” socketpair(2)
产生的FD,以便可以将它们用作“常规”套接字(由net
标准包中的函数产生): / p>
func socketpair() (net.Conn, net.Conn, error) {
fds, err := syscall.Socketpair(syscall.AF_LOCAL, syscall.SOCK_STREAM, 0)
if err != nil {
return nil, nil, err
}
c1, err := fdToFileConn(fds[0])
if err != nil {
return nil, nil, err
}
c2, err := fdToFileConn(fds[1])
if err != nil {
c1.Close()
return nil, nil, err
}
return c1, c2, err
}
func fdToFileConn(fd int) (net.Conn, error) {
f := os.NewFile(uintptr(fd), "")
defer f.Close()
return net.FileConn(f)
}
如果您正在谈论其他类型的I / O,答案是肯定的,系统调用并不便宜,并且如果您必须执行许多操作,则有多种方法可以解决它们的成本(例如卸载到链接或作为外部进程链接的某些C代码),这会以某种方式 batch ,使每次对该C代码的调用都将导致C进行几次系统调用侧面)。