3 ms·

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")

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.

throwaway894345 5y ago
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).
igouy 5y ago
> I'm not sure what the right way to do these… In which case, maybe what you see is as good as you'll get. > … some languages get to preallocate… Here's Go using a library pool — https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-go-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- sirwhinesalot 5y ago
  The sync library is part of Go's standard library and is meant to allow safe concurrent access by multiple goroutines. It's pretty idiomatic Go!
  - igouy 5y ago
    Yes — so "allowed to preallocate memory" ?

throwaway894345 5y ago

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).

igouy 5y ago

> I'm not sure what the right way to do these… In which case, maybe what you see is as good as you'll get. > … some languages get to preallocate… Here's Go using a library pool — https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-go-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

sirwhinesalot 5y ago
The sync library is part of Go's standard library and is meant to allow safe concurrent access by multiple goroutines. It's pretty idiomatic Go!
- igouy 5y ago
  Yes — so "allowed to preallocate memory" ?