CockroachDB学习笔记——[译]Cgo的成本与复杂性
- 原文链接:https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
- 原作者:Tobias Schottdorf
- 原文日期:Dec 9, 2015
- 译:zifeiy
Cgo 是 Go 的一个非常重要的部分:
它是你调用任何任何非Go代码的窗口(或者更确切地说,任何由C语言绑定的东西)。
对于 CockroachDB 来说,
cgo 减轻了我们在处理连接 ROcksDB 的存储层(storage layer)时候的压力,
而 RocksDB 这个存储引擎目前在Go语言生态环境中没有良好的替代品,
至少在我们的任职范围内没有。
经过几次迭代之后,
我们发现处理这些外部库的正确方法——我们有相当多的外部库——是将它们处理后放在Go语言的依赖包(Go wrapper packages)中:
虽然Cgo为我们提供了便利,但是请远没有直接调用那么简单。
经验丰富的Cgo使用者(cgo-er)可能会知道这一点(并且可能更倾向于轻描淡写地在这篇文章的剩余部分上浏览),但是使用Cgo附带一些警告,我们将在下面讨论我们建议的解决方案。
调用的开销(Call Overhead)
调用 Cgo 带来的开销将比在Go语言内部的调用带来的开销大几个数量级。
这听起来很可怕,但实际上在很多应用中都不是问题。
然我们来观察一下这个 cgobench 包:
func BenchmarkCGO(b *testing.B) {
CallCgo(b.N) // call `C.(void f() {})` b.N times
}
// BenchmarkGo must be called with `-gcflags -l` to avoid inlining.
func BenchmarkGo(b *testing.B) {
CallGo(b.N) // call `func() {}` b.N times
}
$ go test -bench . -gcflags '-l' # disable inlining for fairness
BenchmarkCGO-8 10000000 171 ns/op
BenchmarkGo-8 2000000000 1.83 ns/op
换句话说,在这个(公认最小的)例子中,大约有100个因素参与其中。
大家不要因此疯狂。
按照绝对时间,171 ns通常是一个完全可以接受的成本,特别是如果你的C代码做了大量的工作。
然而,在我们的例子中,我们在一些测试中计时了数以万计的Cgo调用,
所以我们把一些代码推到C上以减少迭代次数。
我们的结论是调用开销并不重要,等价的C++和Go的实现在性能上是难以区分的。
然而,由于能够编写更高效的实现,我们仍然将一些操作移到C++上,并进行了fat改进。
手动ISH内存管理(Manual-ish Memory Management)
GO是一门垃圾回收语言,但C不是。
这意味着从C传递数据到Go不应该粗心地进行,并且拷贝常常是不可避免的,反之亦然。
(译者的理解:C语言中的数据不会自动释放,而Go语言中的数据会自动进行垃圾回收,所以在两者之间传输数据的时候可能会碰到数据被提前释放,或者该释放但是没释放的问题)
尤其是(在我们经常)非常频繁地处理字节字符串和接口的时候。
传统的对 C.CString 及 C.GoBytes 的使用会大大增加内存压力,
当然,复制数据也会明显消耗CPU性能。
在一些场景下,我们有办法避免这种类型的拷贝。
举个例子,在便利键的时候,我们使用如下办法:
func (r *rocksDBIterator) Key() []byte {
return C.GoBytes(unsafe.Pointer(r.key), s.len)
}
func (r *rocksDBIterator) Next() {
// The memory referenced by r.key stays valid until the next operation
// on the iterator.
r.key = C.DBNext(r.iter) // cgo call
}
如果我们想要做的是检查一个标准的当前键,我们知道底层内存在我们需要的时候是不会被释放掉的。
因此,这个(编写的)代码似乎是浪费的:
for ; iter.Valid(); iter.Next() {
if bytes.HasPrefix(iter.Key(), someKey) { // copy!
// ...
}
}
为了减轻所有这些拷贝的成本,我们添加(并使用)函数 Key() 的零拷贝(和不安全)版本:
// unsafeKey() returns the current key referenced by the iterator. The memory
// is invalid after the next operation on the iterator.
func (r *rocksDBIterator) unsafeKey() []byte {
// Go limits arrays to a length that will fit in a (signed) 32-bit
// integer. Fall back to copying if our slice is larger.
const maxLen = 0x7fffffff
if s.len > maxLen {
return C.GoBytes(unsafe.Pointer(r.key), s.len)
}
return (*[maxLen]byte)(unsafe.Pointer(s.data))[:s.len:s.len]
}
这看上去是一个更高效和安全的办法,但是在正确使用的时候,它涉及到更多需要考虑的地方。
我们正在创建一个由C分配的内存支持的切片。
我们需要小心,而我们的切片(或任何衍生切片)仍在使用中,而与此同时C内存没有释放。
(译者的理解:C内存没有释放,对切片的改动,不能引起内存的变化,那我们度数据是从内存中读的,
读到的还是原来的数据)
我们可以解决这个问题,因为这个问题出现在我们的底层代码中,但这肯定不是任何类型的面向公众的API的选择;
这将保证一些用户不会遵守对返回的字节切片的微妙契约,并且随机地体验空指针异常。
Cgoroutines != Goroutines
这可能是一个严重的问题,而当你想到它的时候是显而易见的,当你不这样做的时候,它会是一个惊喜。
考虑如下代码:
func main() {
for i := 0; i < 1000; i++ {
go func() {
time.Sleep(time.Second)
}()
}
time.Sleep(2*time.Second)
}
这个无聊的程序不会有多大效果。1000个 gouroutines 几乎免费地来了,分配给它们的“堆栈”只有几千字节。
如果我们把 cgo 带入这个编码游戏呢?
下面的代码是 cgobench 中一个示例的简化版本:
//#include <unistd.h>
import "C"
func main() {
for i := 0; i < 1000; i++ {
go func() {
C.sleep(1 /* seconds */)
}()
}
time.Sleep(2*time.Second)
}
“惊喜”是这段代码的效果(和上面那段)非常不同。
一个阻塞式的 cgo 调用会占用一个系统线程;
Go运行时库 不能像 goroutine 那样调度它们,而堆栈是一个真正的堆栈,其数量是兆字节的!
同样,如果你调用适当的有界并发的 cgo ,那就没什么大不了的。
但是如果你写的话,你可能已经习惯于不太考虑 Goroutines 了。
在关键请求路径中的阻塞cgo调用可能会给你带来成百上千的线程,
这些线程可能会 导致问题。
特别地,ulimit -r
或 debug.SetMaxThreads
可能会导致程序地快速终止。
或者,按照 Dave Cheney 地话来说,
- “过多的 cgo 使用中断 Go 轻量级并发的承诺。”
交叉编译(Cross Out Cross-Compilation)
使用 cgo ,你会丢失(或者更确切地说,你不会很好地体验到)交叉编译在 Go 1.5 或更高把呢不能中工作的易用性。
这并不奇怪(因为交叉编译与C依赖关系必然需要交叉编译C依赖),但是如果您在和Go自己的包或外部库之间进行选择,那么这可能是一个标准。
Dave Cheney在此处发表的一篇文章 通常是关于可用信息的最佳来源。
静态构建(Static Builds)
这种情况和交叉编译的情况类似,不过和交叉编译相比情况较好一点。
使用 cgo 构建静态二进制文件仍然是可能的,但需要进行一些调整。
在Go 1.5之前,最突出的例子是必须使用 netgo 构建标签来避免在 glibc 中链接DNS解析。
这已成为默认的处理方式,
但仍然存在一些微妙之处,
例如必须指定自定义 -installsuffix(以避免使用非静态生成中的缓存生成)、
将正确的标志传递给外部链接器(external linker,在本例中,-extldflags “-static”),
并用 -a 构建以执行一个完全的重建。
不是所有的这些都是必要的,但是你需要明白这一点:
它变得更加手动,并且所有的重建速度都变慢了。
对于所有感兴趣的人来说,
这是我与 cgo 的第一次约会(以及后来的)角斗 和
一个神秘的错误,
我们可以在未来的帖子中再次找到。
调试(Debugging)
调试你的代码会更困难(在使用 cgo 的情况下)。
驻留在C中的部分代码不容易通过Go的工具访问。
PProf、运行时统计(runtime statistics)、行号(line numbers)、
堆栈跟踪(stack traces) —— 当你越过边界时,所有的东西都会减弱。
GoRename 及其朋友可能 偶尔会将源代码中的标识符丢弃 ,
而这些标识符(原本应该)在转换后将转换为 cgo 生成的代码。
由于这些工具通常运行的很好,所以出现的一些损失总会让人感到不安。
但是,gdb仍然有效地工作着。
总结(Summary)
总而言之,cgo 是一个具有局限性的伟大工具。
我们最近开始把一些低级操作转移到C++,这给了一些令人印象深刻的加速。
其他的尝试并没有带来更多地性能提升。
性能地表现不是还令人满意吗?