cgo导出为什么没有基线数据（CGO和CGO）

当我们最开始准备了解 go，并且认识到 golang 在一些场合不可避免的缺乏性能优势的时候(和 c/c 比较)，很多人第一想法是：我为什么不从 go 语言中调用 c 呢，就像在 lua/python 里面做的那样。

go 语言提供了这样的工具，叫做 "cgo", 你也可以用 swig 之类的工具生成大量胶水代码，但是它的核心还是 cgo，但是很快你会发现，事情其实没那么简单 (不同于 lua 和 cpython 等使用 c 开发的解释语言)。最广泛流传的一篇警告来自 Go 语言的作者之一 Dave Cheney, cgo is not Go, 这篇文章告诫我们，cgo 的缺点很多：

1. 编译变慢，实际会使用 C 语言编译工具，还要处理 c 语言的跨平台问题
2. 编译变得复杂
3. 不支持交叉编译
4. 其他很多 go 语言的工具不能使用
5. C 与 Go 语言之间的的互相调用繁琐，是会有性能开销的
6. C 语言是主导，这时候 go 变得不重要，其实和你用 python 调用 c 一样
7. 部署复杂，不再只是一个简单的二进制

另几篇警告：一篇来自 GopherCon2016 的一篇演讲 From cgo back to Go,还有一篇来自 cockroachdb的作者 这两篇文章作者讲述了其在实际使用中遇到的其他困难（还有一些和上面的重复）：

1. 内存管理变得复杂，C 是没有垃圾收集的，而 go 有，两者的内存管理机制不同，可能会带来内存泄漏
2. Cgoroutines != Goroutines，如果你使用 goroutine 调用 c 程序，会发现性能不会很高：Excessive cgo usage breaks Go’s promise of lightweight concurrency.

这些困难可以分为几种

1. 编译问题：慢、不能交叉变异
2. 配套工程问题：go 工具链不能完全使用 如 profile，doc 等等
3. 性能问题：调用的性能开销
4. 开发问题：需要细心管理 C 指针，否则很容易带来泄漏

其中 1，2 是我们可以容忍的，4 在 From cgo back to Go 作者给了一些提示，实际上我相信如果不是特别大量的交叉使用，也是可以避免的。那么最核心的就是 3了，性能到底开销有多大呢。毕竟 我们想使用 cgo 的出发点就是为了性能.

想了解这一点除了官方文档，我们还需要知道一点汇编, 了解相关的技术1, 2

首先 Cgo isn't an FFI system 这点就和 python，lua 等调用 c 的方式很不同. Cgo在编译的时候会为代码生成大量的中间文件。 在一个Go源文件中，如果出现了import "C"指令则表示将调用cgo命令生成对应的中间文件。

比如一个 main.go 文件

package main

执行 go tool cgo main.go (go 版本 1.14), 会生成

. ├── _obj │ ├── _cgo_.o │ ├── _cgo_export.c │ ├── _cgo_export.h │ ├── _cgo_flags │ ├── _cgo_gotypes.go │ ├── _cgo_main.c │ ├── main.cgo1.go │ └── main.cgo2.c └── main.go

先看 main.cgo1.go, 这是展开虚拟C包相关函数和变量后的Go代码, 内部会实际调用 (_Cfunc_sum)(1, 1), 每一个C.xxx形式的函数都会被替换为_Cfunc_xxx格式的纯Go函数，其中前缀_Cfunc_表示这是一个C函数，对应一个私有的Go桥接函数。

package main import _ "unsafe" func main() { println(( _Cfunc_sum )(1, 1)) }

桥接函数 _Cfunc_sum 定义为:

func _Cfunc_sum(p0 _Ctype_int, p1 _Ctype_int) (r1 _Ctype_int) { _cgo_runtime_cgocall(_cgo_e119c51a7968_Cfunc_sum, uintptr(unsafe.Pointer(&p0))) if _Cgo_always_false { _Cgo_use(p0) _Cgo_use(p1) } RETurn }

其中_cgo_runtime_cgocall 对应runtime.cgocall函数，函数的声明如下, 其中调用的第一个参数为 cgo 函数，第二个参数未所有的参数：

func runtime.cgocall(fn, arg unsafe.Pointer) int32

被传入C语言函数_cgo_506f45f9fa85_Cfunc_sum也是cgo生成的中间函数。函数在main.cgo2.c定义, 可以看出所有参数都封装到一个结构里面了：

void _cgo_e119c51a7968_Cfunc_sum(void *v) { struct { int p0; int p1; int r; char __pad12[4]; } __attribute__((__packed__)) *_cgo_a = v; char *_cgo_stktop = _cgo_topofstack(); __typeof__(_cgo_a->r) _cgo_r; _cgo_tsan_acquire(); _cgo_r = sum(_cgo_a->p0, _cgo_a->p1); _cgo_tsan_release(); _cgo_a = (void*)((char*)_cgo_a (_cgo_topofstack() - _cgo_stktop)); _cgo_a->r = _cgo_r; _cgo_msan_write(&_cgo_a->r, sizeof(_cgo_a->r)); }

然后从参数指向的结构体获取调用参数后开始调用真实的C语言版sum函数，并且将返回值保持到结构体内返回值对应的成员。

因为Go语言和C语言有着不同的内存模型和函数调用规范。其中_cgo_topofstack函数相关的代码用于C函数调用后恢复调用栈。_cgo_tsan_acquire和_cgo_tsan_release则是用于扫描CGO相关的函数则是对CGO相关函数的指针做相关检查。

其中runtime.cgocall函数是实现Go语言到C语言函数跨界调用的关键。

runtime.cgocall 的定义在 runtime/cgocall.go:97 (go 1.14) 核心代码如下

func cgocall(fn, arg unsafe.Pointer) int32 { mp := getg().m mp.ncgocall mp.ncgo mp.cgoCallers[0] = 0 entersyscall() osPreemptExtEnter(mp) mp.incgo = true errno := asmcgocall(fn, arg) mp.incgo = false mp.ncgo-- osPreemptExtExit(mp) exitsyscall() if raceenabled { raceacquire(unsafe.Pointer(&racecgosync)) } KeepAlive(fn) KeepAlive(arg) KeepAlive(mp) return errno }

asmcgocall 的定义（go1.14 amd64）在 runtime/asm_amd64.s:615

TEXT ·asmcgocall(SB),NOSPLIT,$0-20 MOVQ fn 0(FP), AX MOVQ arg 8(FP), BX MOVQ SP, DX get_tls(CX) MOVQ g(CX), R8 CMPQ R8, $0 JEQ nosave MOVQ g_m(R8), R8 MOVQ m_g0(R8), SI MOVQ g(CX), DI CMPQ SI, DI JEQ nosave MOVQ m_gsignal(R8), SI CMPQ SI, DI JEQ nosave MOVQ m_g0(R8), SI CALL gosave<>(SB) MOVQ SI, g(CX) MOVQ (g_sched gobuf_sp)(SI), SP SUBQ $64, SP ANDQ $~15, SP MOVQ DI, 48(SP) MOVQ (g_stack stack_hi)(DI), DI SUBQ DX, DI MOVQ DI, 40(SP) MOVQ BX, DI MOVQ BX, CX CALL AX get_tls(CX) MOVQ 48(SP), DI MOVQ (g_stack stack_hi)(DI), SI SUBQ 40(SP), SI MOVQ DI, g(CX) MOVQ SI, SP MOVL AX, ret 16(FP) RET nosave: SUBQ $64, SP ANDQ $~15, SP MOVQ $0, 48(SP) MOVQ DX, 40(SP) MOVQ BX, DI MOVQ BX, CX CALL AX MOVQ 40(SP), SI MOVQ SI, SP MOVL AX, ret 16(FP) RET

C.sum的整个调用流程图如下

Go --> runtime.cgocall --> runtime.entersyscall --> runtime.asmcgocall --> _cgo_Cfunc_f | | Go <-- runtime.exitsyscall <-- runtime.cgocall <-- runtime.asmcgocall <----------

这里有一个性能测试 不过时间比较久远了，内部显示 如果是单纯的 emtpy call，使用 cgo 耗时 55.9 ns/op， 纯 go 耗时 0.29 ns/op，相差了 192 倍。

而实际上我们在使用 cgo 的时候不太可能进行空调用，一般来说会把性能影响较大，计算耗时较长的计算放在 cgo 中，如果是这种情况，每次条用额外 55.9 ns 的额外耗时应该是可以接受的访问。

为了测试这种情况，这里设计了更全面的一种测试.

package main import ( "fmt" "time" ) import "C" func calSum(c int) { sum := 0 for i := 0; i <= c; i { sum = i } } func main() { cycles := []int{500000, 1000000, 5000000, 10000000} counts := []int{10, 50, 100, 500, 1000, 5000, 10000} for _, count := range counts { for _, cycle := range cycles { startCgo := time.Now() for i := 0; i < cycle; i = i 1 { C.calSum(C.int(count)) } costCgo := time.Now().Sub(startCgo) startGo := time.Now() for i := 0; i < cycle; i = i 1 { calSum(count) } costGo := time.Now().Sub(startGo) fmt.Printf("count: %d, cycle: %d, cgo: %s, go: %s, cgo/cycle: %s, go/cycle: %s cgo/go: %.4f \n", count, cycle, costCgo, costGo, costCgo/time.Duration(cycle), costGo/time.Duration(cycle), float64(costCgo)/float64(costGo)) } } }

在我的电脑

MacBook Pro (16-inch, 2019) 2.6 GHz 6 core Intel Core i7; 32 GB 2667 MHz DDR4 下的测试结果如下

count: 10, cycle: 500000, cgo: 34.420728ms, go: 2.8631ms, cgo/cycle: 68ns, go/cycle: 5ns cgo/go: 12.0222 count: 10, cycle: 1000000, cgo: 54.821951ms, go: 5.143633ms, cgo/cycle: 54ns, go/cycle: 5ns cgo/go: 10.6582 count: 10, cycle: 5000000, cgo: 276.215279ms, go: 23.72644ms, cgo/cycle: 55ns, go/cycle: 4ns cgo/go: 11.6417 count: 10, cycle: 10000000, cgo: 547.493103ms, go: 47.903742ms, cgo/cycle: 54ns, go/cycle: 4ns cgo/go: 11.4290 count: 50, cycle: 500000, cgo: 27.33682ms, go: 11.255556ms, cgo/cycle: 54ns, go/cycle: 22ns cgo/go: 2.4287 count: 50, cycle: 1000000, cgo: 55.332225ms, go: 22.576177ms, cgo/cycle: 55ns, go/cycle: 22ns cgo/go: 2.4509 count: 50, cycle: 5000000, cgo: 275.125825ms, go: 111.686179ms, cgo/cycle: 55ns, go/cycle: 22ns cgo/go: 2.4634 count: 50, cycle: 10000000, cgo: 548.110691ms, go: 221.686657ms, cgo/cycle: 54ns, go/cycle: 22ns cgo/go: 2.4725 count: 100, cycle: 500000, cgo: 26.850102ms, go: 17.105866ms, cgo/cycle: 53ns, go/cycle: 34ns cgo/go: 1.5696 count: 100, cycle: 1000000, cgo: 55.683324ms, go: 34.013477ms, cgo/cycle: 55ns, go/cycle: 34ns cgo/go: 1.6371 count: 100, cycle: 5000000, cgo: 274.983861ms, go: 175.353445ms, cgo/cycle: 54ns, go/cycle: 35ns cgo/go: 1.5682 count: 100, cycle: 10000000, cgo: 565.807779ms, go: 332.529274ms, cgo/cycle: 56ns, go/cycle: 33ns cgo/go: 1.7015 count: 500, cycle: 500000, cgo: 28.107866ms, go: 67.736173ms, cgo/cycle: 56ns, go/cycle: 135ns cgo/go: 0.4150 count: 500, cycle: 1000000, cgo: 55.675557ms, go: 132.092526ms, cgo/cycle: 55ns, go/cycle: 132ns cgo/go: 0.4215 count: 500, cycle: 5000000, cgo: 274.076029ms, go: 662.014685ms, cgo/cycle: 54ns, go/cycle: 132ns cgo/go: 0.4140 count: 500, cycle: 10000000, cgo: 549.303546ms, go: 1.339623927s, cgo/cycle: 54ns, go/cycle: 133ns cgo/go: 0.4100 count: 1000, cycle: 500000, cgo: 27.844244ms, go: 129.589541ms, cgo/cycle: 55ns, go/cycle: 259ns cgo/go: 0.2149 count: 1000, cycle: 1000000, cgo: 55.454138ms, go: 256.596273ms, cgo/cycle: 55ns, go/cycle: 256ns cgo/go: 0.2161 count: 1000, cycle: 5000000, cgo: 277.258613ms, go: 1.286156417s, cgo/cycle: 55ns, go/cycle: 257ns cgo/go: 0.2156 count: 1000, cycle: 10000000, cgo: 547.58263ms, go: 2.529370786s, cgo/cycle: 54ns, go/cycle: 252ns cgo/go: 0.2165 count: 5000, cycle: 500000, cgo: 27.813485ms, go: 623.126501ms, cgo/cycle: 55ns, go/cycle: 1.246µs cgo/go: 0.0446 count: 5000, cycle: 1000000, cgo: 54.529121ms, go: 1.232225252s, cgo/cycle: 54ns, go/cycle: 1.232µs cgo/go: 0.0443 count: 5000, cycle: 5000000, cgo: 276.45882ms, go: 6.182891022s, cgo/cycle: 55ns, go/cycle: 1.236µs cgo/go: 0.0447 count: 5000, cycle: 10000000, cgo: 610.406629ms, go: 12.620529682s, cgo/cycle: 61ns, go/cycle: 1.262µs cgo/go: 0.0484 count: 10000, cycle: 500000, cgo: 28.357581ms, go: 1.343704285s, cgo/cycle: 56ns, go/cycle: 2.687µs cgo/go: 0.0211 count: 10000, cycle: 1000000, cgo: 58.956701ms, go: 2.688045373s, cgo/cycle: 58ns, go/cycle: 2.688µs cgo/go: 0.0219 count: 10000, cycle: 5000000, cgo: 280.817687ms, go: 12.719011833s, cgo/cycle: 56ns, go/cycle: 2.543µs cgo/go: 0.0221 count: 10000, cycle: 10000000, cgo: 562.932582ms, go: 25.596832236s, cgo/cycle: 56ns, go/cycle: 2.559µs cgo/go: 0.0220

将 cgo 和 go 调用的耗时对比统计为图表：

image1.png

image2.png

可以看出 随着 count 数量增加，即实际计算量的增加，cgo 的性能优势逐渐体现，这时候 cgo 的性能 overhead 变得可以忽略不计了 (备注：这里 gcc 默认有编译优化，当关闭编译优化时，还是能看出显著 cgo/go 下降趋势的)。

相关的代码和数据在 https://github.com/u2takey/cgo-bench

• Adventures With cgo
• The Cost and Complexity of Cgo
• cgo编程
• cgo
• Go 语言原本