3 ms·

Highly unlikely Go will be more performant than the JVM. Why not? C still beats Java in many cases (e.g. numeric code) thanks to compiler optimisation and I se

Highly unlikely Go will be more performant than the JVM. Why not? C still beats Java in many cases (e.g. numeric code) thanks to compiler optimisation and I see little reason why (outside garbage collection) Go cannot achieve similar compile time optimisation (in fact, inlining should be easier than in C). Besides that, Go gives more opportunity for optimisation since it has value types. Also, in my personal experience (having written a fair share of natural language processing tools in Go and Java), they are approximately in the same ballpark performance-wise. More synthetic benchmarks such as the Computer Language Benchmarks Game seem to confirm this. And there is definitely still more low-hanging fruit in Go optimisation. Why not use Java or .Net instead of Go? Because I value the Unix tradition and like small standalone binaries with quick startup time more than dragging around a JVM (although I use Java to for projects)? Because it has value types? Because it is easier to call C from Go? Because I like its profiler more?

Jweb_Guru 12y ago
Inlining is actually something JITs are really good at... I'm not sure why you think it would be easier in Go than in C, but the relevant angle is the JVM. Go's value types are hyped up, but they're really not that great. Taking a reference instantly heap-allocates them, C# already has them, and Java is getting them too (in 10). Calling into C from Go is easier than in Java, but it's not any faster (in fact, it's generally slower, because you can't call into it without switching away from one of Go's tiny stacks into one that the C expects). One of the unfortunate consequences of this is that optimizing a hot loop by calling out to C doesn't work nearly as well in Go as it does in many other languages. As far as general points about AOT compilation: many don't apply to go compile simply because it will not waste the time to actually perform those optimizations, because it is very focused on its goal of compilation speed. gccgo, sure.

Jweb_Guru 12y ago

Inlining is actually something JITs are really good at... I'm not sure why you think it would be easier in Go than in C, but the relevant angle is the JVM. Go's value types are hyped up, but they're really not that great. Taking a reference instantly heap-allocates them, C# already has them, and Java is getting them too (in 10). Calling into C from Go is easier than in Java, but it's not any faster (in fact, it's generally slower, because you can't call into it without switching away from one of Go's tiny stacks into one that the C expects). One of the unfortunate consequences of this is that optimizing a hot loop by calling out to C doesn't work nearly as well in Go as it does in many other languages. As far as general points about AOT compilation: many don't apply to go compile simply because it will not waste the time to actually perform those optimizations, because it is very focused on its goal of compilation speed. gccgo, sure.