You can't really trust the computer language benchmark's game. Many of the solutions there have code that's as far from idiomatic as possible (nobody would write code like that in real production applications).
That said, two things:
1. Go is not particularly efficient as a language and its compiler doesn't optimize much compared to the other "efficient" language compilers (even the JIT ones).
2. These small benchmarks benefit JIT languages quite a bit since the JIT cost is barely noticeable. In large real-world apps constantly running a compiler in the back is not exactly efficient. It'll pay for itself vs interpreted languages, but never against AOT compiled ones.
> Go is not particularly efficient as a language and its compiler doesn't optimize much compared to the other "efficient" language compilers (even the JIT ones).
I mean, relative to many other mainstream languages including many of the JIT languages, Go is very efficient, but a lot of that efficiency comes from the language design (e.g., idiomatic value types) such that the compiler and runtime don’t need to be as smart.
Agreed that the benchmarks game is a pretty crumby measure of performance, but it typically imposes strange restrictions on Go that prevents it from showing its idiomatic performance (never mind its ceiling). For example, languages with garbage collectors aren’t allowed to preallocate memory for certain benchmarks even though that’s absolutely idiomatic in Go (because Go has value types) so you have languages with GCs optimized for languages where everything is an allocation which perform well and languages like C and Rust which are allowed to preallocate because they don’t have a GC (which is a weird criteria) and then you have Go which appears to be very slow because it’s forced to allocate in a tight loop.
Yes Go's design is not bad as far as efficiency goes, but it's not amazing either.
From a language design perspective (when it comes to "ease of optimization") it's much better than Java and comparable to C#.
But compiling C# with CoreRT (which is basically .NET Core's RyuJIT configured as an AOT compiler) shows just how little Go's compiler optimizes. Go would need to be even more "easy to optimize" than it is to make up the difference. Rust and C++ are both easier to optimize and their compilers are in a whole other league entirely, and it shows on the horrific compilation speeds.
I'm not sure what the right way to do these "benchmarks" is. Some of the code I've seen there was more low level and convoluted than stuff I'd write in C. Not even remotely representative of how the languages are used. Stupid rules like that one you mentioned also don't help since some languages get to preallocate and others don't.
Agreed--Go isn't in the top tier of languages with respect to efficiency--the languages in this tier trade off a lot of other facets to get high performance, and those tradeoffs don't align well with Go's goals. That said, I would be curious what sorts of optimizations Go could add which would pay for themselves with respect to keeping compile times fast. I don't know a lot about compiler optimizations, but I find the topic very interesting at least as it pertains to languages I use (I really don't care much about Haskell or OCaml or any of the other PLT darlings).
The C++ and Swift implementations use a node pool from the Apache Portable Runtime. This benchmark would be a lot more interesting if we got to see the price of C++'s RAII or Swift's reference counting.
The Swift Code looks like something you'd write in C.
No, that’s not an actual quotation. I was having a laugh at the silly logic which attempts to justify the benchmark. And preallocating isn’t a workaround, it’s idiomatic in Go.
And that’s a valid point for the set of applications whose purpose is generating garbage. But overwhelmingly this isn’t interesting and people mistake this benchmark for a useful indicator of programming language performance in the general case.
It’s not a very compelling defense of a benchmark to argue that it measures something different for some languages than others—in this case for Go the benchmark measures poorly/carelessly written code while for other languages it measures meticulously optimized code.
I maintain a contrived benchmark is not a useful benchmark.
Well, I randomly went and opened the C# binary tree example. I see a TreeNode struct with a private Next class inside of it. Can't think of any reason to write a BinaryTree like that in C# beyond trying to game some benchmarks.
The C++ implementation uses a node pool from the Apache Portable Runtime (a C library). Also not idiomatic (how did they get away with using a library?!). I particularly love how it doesn't even use std::string to write text to.
The Swift implementation also uses the Apache Portable Runtime node pool, completely non-idiomatic (even less justifiable than the C++ one), don't need to go into detail on this one.
The Go and Java implementations look perfectly normal for the respective languages.
The Dart one too, but that one doesn't even use any concurrency so it's starting from a losing position.
If it wasn't massively more performant than other ways to write that program in C#, then maybe it's just fine for the purposes of "Energy Efficiency across Programming Languages".
> … but that one doesn't even use any concurrency…
What is the relationship between multicore and energy efficiency?
> This is not a fair comparison.
The comparison is energy efficiency not elapsed seconds, yes?
Comparing the energy efficiency of code that's not even doing the same thing is not a useful comparison. If you're running these benchmarks on a server that's always running full throttle then using more cores will use less power because the software finishes faster. If you're running on a laptop the relationship between core usage, elapsed seconds, and power usage is very non-linear.
That said, two things:
1. Go is not particularly efficient as a language and its compiler doesn't optimize much compared to the other "efficient" language compilers (even the JIT ones).
2. These small benchmarks benefit JIT languages quite a bit since the JIT cost is barely noticeable. In large real-world apps constantly running a compiler in the back is not exactly efficient. It'll pay for itself vs interpreted languages, but never against AOT compiled ones.