gccgo vs go calling overhead with C, few questions about gccgo

<p>As some people may know already, Go (go standard compiler) has relatively significant limitation when using with C code. Each call of C function has minimal overhead of 120-180ns per call (benchmarks vary), even for empty functions. Reasons are justified and non trivial.</p> <p>This limitation won&#39;t be felt in all usage cases, it depends on how often do you want to make calls. It is of particular interest to me as I have a hobby OpenGL project that has to make large number (10000+) of OpenGL calls (glMultMatrix, glCallList) per second with tight time budget, so any overhead is deal breaker.</p> <p>Enter gccgo compiler. It has no calling overhead with C. My non trivial benchmarks with C, Go-go and Go-gccgo compiled code that uses GLFW and OpenGL C libraries confirm that Go program compiled with gccgo is as fast as C program. Go program compiled with standard compiler is order of magnitude slower and unusable due to overhead.</p> <p>I have been searching web for more information about gccgo, but it is pretty scarce.</p> <p>What I&#39;m interested is to hear more information from authors and more informed users of gccgo: what is future of gccgo, will it be maintained, what are the plans? How will gccgo fare now that runtime in Go 1.5 has been moved from C to pure Go? As far as I know, gccgo shares Go&#39;s runtime (with GC) written in C, does this means that post 1.5 improvements will not affect gccgo?</p> <p>To summarize, I think that gccgo is extremely valuable tool, not only because of described problem it solves, but for many other optimizations it makes possible. And coupled with constantly improving GC it may make Go excellent choice for high performance games.</p> <hr/>**评论：**<br/><br/>Fwippy: <pre><p>You may want to expand the C code section, to reduce the number of cross go-&gt;C calls. For example, bundle/batch the calls you need to make or the data you need to send, then call a C function supplying the batch, which sends the appropriate OpenGL commands.</p> <p>As far as I know, there are no plans to scrap or deprecate gccgo. It will usually be a minor version or two behind the regular compiler, see notes here: <a href="https://tip.golang.org/doc/go1.6#gccgo">https://tip.golang.org/doc/go1.6#gccgo</a></p></pre>DualRearWheels: <pre><p>This is &#34;hack&#34; used with Go&#39;s standard compiler, and as discussed in gamedev sections (can&#39;t find links) it just moves overhead to data preparation/copy phase instead of function call phase. This can be avoided completely with gccgo.</p></pre>funny_falcon: <pre><p>As I can understand, gccgo shares stanfard library, so it provides compatibility for user code. But it doesn&#39;t share (or share a little of) runtime: it has no exact stack traversing, no copying stack increase and no cocurrent GC; instead it uses conservative STW GC and native stack, that is why calling C functions is cheap.</p></pre>DualRearWheels: <pre><p>I can&#39;t find link I read it from, but I think gccgo uses Go&#39;s runtime which, up to 1.5, used parallel STW garbage collector. From 1.5 runtime is in pure Go and uses concurrent GC. It is a big change that enabled much better performance. I am no GC expert here so I am not sure if I am understanding this correctly.</p></pre>Ainar-G: <pre><p>AFAIK, <a href="https://github.com/golang/gofrontend" rel="nofollow">gccgo</a> uses its own version of Go runtime (see libgo/runtime) as well as its own modified stdlib (libgo/go). I don&#39;t know about what kind of GC they use at the moment (golang-nuts/golang-dev might be good places to ask) but it also lacks escape analysis (which means more heap allocations, although this is being worked on ATM) and true goroutines (last time I&#39;ve checked, gccgo would map goroutines to threads 1:1 instead of N:1).</p> <p>Oh, and I don&#39;t think gccgo is going to be abandoned any time soon. There is also <a href="http://reviews.llvm.org/diffusion/L/browse/llgo/trunk/" rel="nofollow">llgo</a> for LLVM, but it&#39;s still not quite &#34;production ready&#34; if I recall correctly.</p></pre>DualRearWheels: <pre><blockquote> <p>Oh, and I don&#39;t think gccgo is going to be abandoned any time soon. There is also llgo for LLVM, but it&#39;s still not quite &#34;production ready&#34; if I recall correctly.</p> </blockquote> <p>This is nice to hear. Thank you, I didn&#39;t know about llgo.</p></pre>computesomething: <pre><blockquote> <p>what is future of gccgo, will it be maintained, what are the plans?</p> </blockquote> <p>I haven&#39;t kept up on gccgo, although I haven&#39;t benchmarked calls to &#39;C&#39;, I remember that in some benches I did gccgo outperformed Go by a good margin, on others (which typically were more runtime-dependent) it lost by a good margin.</p> <p>I recall that one of the problems with Gccgo optimization was that it lacked escape analysis which meant it allocated from heap when it could do much cheaper stack allocations.</p> <p>Anyway I think Ian Lance Taylor is the maintainer of gccgo, if you are really interested I think your best bet is to send him an e-mail.</p></pre>DualRearWheels: <pre><p>Thanks, it is something I suspected as well. Performance can&#39;t be mirrored as they are different beasts underneath. From what I read too gccgo has advantage in computation part (due to lot of gcc optimizations over the years) while standard go is better with memory allocation (not a necessary bad thing for GC games where one must be careful anyway with memory).</p></pre>si6pak: <pre><p>Wrong.</p> <p>You write games in C++. Go is a more appropriate choice for a game network server.</p></pre>computesomething: <pre><p>Ehh... lots of people write games in Java (Minecraft for example), C# (XNA, Monogame), Javascript, etc, against which Go performs very well.</p></pre>DualRearWheels: <pre><p>Exactly, and even more importantly math operations with matrices and vectors are as fast as C, which is very important for 3d games as it is often CPU bottleneck too.</p></pre>si6pak: <pre><p>Go was made for concurrency, games are best written in a lock step single threaded pattern, as it can be very hard to synchronize everything 60 times a second. So write you client in C++/Java/C#, enjoy the native C calling convention support, and write your network server in Go. It&#39;s what it was made for.</p></pre>