5 ms·

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

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

sirwhinesalot 5y ago
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" ?
igouy 5y ago
> … aren’t allowed to preallocate memory… Because as-you-know the whole point is to "allocate zillions of short-lived nodes" — https://news.ycombinator.com/item?id=29323468 https://news.ycombinator.com/item?id=29323468
- deleted 5y ago
  [deleted]
- throwaway894345 5y ago
  “It’s not a bad benchmark, it’s just showcasing a contrived scenario with different sets of rules for different kinds of languages”. Most people aren't building applications whose business requirements preclude preallocating memory except for languages which lack garbage collectors.
  - igouy 5y ago
    So those are scare quotes not actually quotation? If we don't experience a performance problem, we don't need a workaround.
    - throwaway894345 5y ago
      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.
      - igouy 5y ago
        That is not a contradiction: it can be both idiomatic in Go and a workaround to avoid garbage collection.
        throwaway894345 5y ago
        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.

sirwhinesalot 5y ago

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

igouy 5y ago

> … aren’t allowed to preallocate memory… Because as-you-know the whole point is to "allocate zillions of short-lived nodes" — https://news.ycombinator.com/item?id=29323468 https://news.ycombinator.com/item?id=29323468

deleted 5y ago
[deleted]
throwaway894345 5y ago
“It’s not a bad benchmark, it’s just showcasing a contrived scenario with different sets of rules for different kinds of languages”. Most people aren't building applications whose business requirements preclude preallocating memory except for languages which lack garbage collectors.
- igouy 5y ago
  So those are scare quotes not actually quotation? If we don't experience a performance problem, we don't need a workaround.
  - throwaway894345 5y ago
    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.
    - igouy 5y ago
      That is not a contradiction: it can be both idiomatic in Go and a workaround to avoid garbage collection.
      - throwaway894345 5y ago
        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.