<p>目前，当Go需要和C/C++代码集成的时候，大家最先想到的肯定是CGO。毕竟是官方的解决方案，而且简单。</p>    <p>但是CGO是非常慢的。因为CGO其实一个桥接器，通过自动生成代码，CGO在保留了C/C++运行时的情况下，搭建了一个桥来沟通C/C++世界和Go的世界。这就意味着，兼容性很好，但是对C的函数的调用，必须先把当前的goroutine挂起，并切换执行栈到当前的线程M的主栈（大小2MB）。如果不做这个操作，那么只能在goroutine的栈上执行C函数调用，可是，goroutine的栈一般都很小，很容易就导致了栈溢出了。</p>    <p>调用C函数的时候，必须切换当前的栈为线程的主栈，这带来了两个比较严重的问题：</p>    <ol>     <li>线程的栈在Go运行时是比较少的，受到P/M数量的限制，一般可以简单的理解成受到GOMAXPROCS限制；</li>     <li>由于需要同时保留C/C++的运行时，CGO需要在两个运行时和两个ABI（抽象二进制接口）之间做翻译和协调。这就带来了很大的开销。</li>    </ol>    <p>minio项目的一个副产品是 <a href="/misc/goto?guid=4959754392577596974" rel="nofollow">c2goasm</a> 项目，这个项目也被 <a href="/misc/goto?guid=4959754392671727805" rel="nofollow">go-cv-simd</a> 项目使用获得了很好的效果。</p>    <p>c2goasm 的角色是一个 汇编语言转换器，输入是 clang输出的amd64汇编，输出是go汇编。而clang的输入是C/C++语言。限制是不能有RTTI和异常。也就是说不能有C/C++运行时提供的高级功能。</p>    <p>c2goasm输出的go汇编，交给go的工具链可以直接生成go的可执行代码。</p>    <p>c2goasm和CGO比，最大的改进就是：</p>    <ol>     <li>不再有C/C++运行时，也就没了在两者之间不停转换的逻辑开销；</li>     <li>不需要切换到线程的主栈来执行函数，因为c2goasm生成的是纯正的go函数，不需要线程的主栈就可以执行；</li>    </ol>    <p>由此就极大的改进了性能，代价是兼容性和可移植性损失了。</p>    <p><img alt="如何把Go调用C的性能提升10倍？" src="https://simg.open-open.com/show/2c33080fb8d90a2f02282be334ce6d1c.png" width="825" height="223"></p>    <p>via:https://my.oschina.net/linker/blog/1529928</p>    <p> </p>