| > The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++) Go 1.7 performs nowhere near the set of optimizations that GCC and LLVM do. GCC/LLVM have a huge number of algebraic simplifications (InstCombine), aggressive alias analysis, memory dependence analysis, instruction scheduling, an optimized instruction selector, a highly tuned register allocator with stuff like rematerialization, SCCP, etc. etc. It will take years and years for Golang to come close. > Go (the language) can be made just as fast as C (the language), for many cases. No, it can't. The M:N scheduling model will always have some overhead relative to 1:1 if you don't need the performance profile of C10K-style servers. The dynamic semantics of "defer" is an unavoidable performance tax over RAII. Unwinding is mandated by the language, inhibiting some optimizations. There is little control over allocation: language constructs allocate in ways that are not immediately obvious. The fact that interfaces result in huge numbers of virtual calls results in a good amount of overhead that (unlike Java) Go can't even eliminate with inline caching, because it's AOT compiled. This is just off the top of my head. > Go has the advantage of making it much easier to use multiple processors, though. Not really. Go's parallelism primitives are just as low-level as those of C. The "one size fits all" scheduling algorithm is a poor fit for getting the most performance out of multicore. The lack of generics is a real problem: it prevents you from using optimized concurrent data structures without paying the tax of interface{} or going through code generation hoops. In any case, the lack of SIMD basically kills Go's applicability in these domains. |