Lin*_*ope 10
Cgo相当慢,因为Go必须以某种方式混淆其运行时和调用约定来调用C函数.它真正值得的唯一地方是计算时间显着使这个成本相形见绌的情况.它类似于并行,分布式,GPU等编程,虽然启动成本略低.
汇编要好得多,因为你可以编写使用Go的调用约定的汇编,并且在其他方面被视为本机Go代码,但汇编的可移植性更差,更难阅读,维护更多.事实上,Go标准库在Plan 9风格的程序集中编写了一些math和big包.
Gonum就是这两个例子.它使用通用程序集来实现某些功能,可以通过这种方式更快地完成,但它也可以利用blas和lapack引擎.它确实提供了一个Go-blas实现,但C-blas(通常最终是Fortran-blas)更快,而对于大型矩阵计算,几乎总是使离开Go的成本相形见绌.
通常,您希望尽可能避免使用cgo.仅在需要大量计算时间时使用它,或者您需要与纯Go中交互的事物(如图形或音频驱动程序)或访问OpenCV等公共库进行交互.即使这样,如果你真的关心性能,在可能的情况下实现某种"调用池"可能是值得的,你可以从Go端调度多个调用,并通过单个上下文切换到C来一次执行它们.
编辑:至于C++,有一些重大问题.如果没有多层抽象,可能很难包装某些库(因为cgo无法正确处理包含的C++头文件).另外,带有析构函数的C++类实际上不能通过值返回,必须在堆上进行分配.由于Go不允许确定性地完成资源,因此必须提供显式释放内存的功能,并且Go用户必须记住释放资源.(你可以在文档中看到一个函数,runtime.SetFinalizer但我不能说我见过有人使用它,文档本身附带了一些警告)
这样的功能defer使其更易于管理,但它破坏了很多像RAII这样使现代C++实践更安全的东西.