3 ms·

> Optimized Go code will generally perform on par with optimized Rust code. This is an incredibly dangerous assumption. Go and Rust are in a completely differe

> Optimized Go code will generally perform on par with optimized Rust code. This is an incredibly dangerous assumption. Go and Rust are in a completely different weight class of compiler capability. Before making an assumption like this, I strongly suggest building a sample application (that is more complex than hello world) in Go and Rust, then compiling both with optimizations and taking a peek at what they compile to with Ghidra/IDA Pro/any other disassembler. C# + .NET 8 can sometimes trade blows with Rust + LLVM, particularly with struct generics, but Go definitely can't, is far behind in compiler features and doesn't leverage techniques that reduce cost of non-free abstractions that .NET and OpenJDK employ.

kbolino 2y ago
I should clarify that by "optimized" I meant hand optimized, not just compiler optimized. You can easily code yourself into surprisingly poor performance with Go, though usually for the same/similar reasons as C#/Java. Rust makes it a little harder to get into the same situations though it's by no means impossible. As to the zero/low-cost abstractions, Go has very few abstractions at a language level and that is what I meant by "much less expressive". If you try too hard to write Go as though it were another language, you will shoot yourself in the foot. However the Go compiler, standard library, and broader ecosystem have come a long way and enable very similar performance profiles to most other compiled languages. It has not been my experience, at least in micro-benchmarks, to see any major performance differences in Go vs e.g. C on things like encryption, hashing, RNG, SIMD, etc. You do need to avoid allocations in hot code paths but that's true of any garbage-collected language. The outstanding performance issues I'm aware of are around deferring, calling methods through an interface, and calling out to cgo. These are pretty minor in most situations but can eat up a lot of CPU cycles if done often in tight loops. They've also been getting better over time and can sometimes be optimized away with PGO.
- neonsunset 2y ago
  This is fair but performant data processing in Go simply has much lower performance ceiling than Rust, C#, Swift or C++. Which is why all standard library routines that do so (text search, hashing, encryption, etc.) are written in Go's custom """portable""" ASM dialect. It is unwieldy and has API omissions because it takes this half-assed approach many things in Golang ecosystem do. The closer, and better, example is hand-optimized C# where you still (mostly) write portable and generic code for SIMD routines and they get compiled to almost the same codegen as hand-intrinsified C++. I understand where this belief comes from, but the industry at large does itself a huge disservice by tunnel visioning at a handful of (mostly subpar) technologies.
  - Thaxll 2y ago
    I think you over hype c# and swift, we did benchmark a grpc api server in c# ( net core ) and Go, same implementation in both languages and Go while faster was using way less memory.
    - neonsunset 2y ago
      Was that with .NET 8? There have been significant performance improvements with each subsequent version in the last 5 years.
  - kbolino 2y ago
    Unfortunately, you are right that SIMD support in Go isn't great and basically requires writing platform-specific code in their quirky assembly language or using a third-party library which does that for you. I don't think the existing use of assembly under the hood to accelerate performance when possible is something to be frowned upon though. It's an implementation detail that almost never matters. One issue with the performance of their assembly code though is that it passes arguments and return values on the stack. I saw something about allowing code to use registers instead but I don't think it's available yet.
    - meling 2y ago
      Support for register-based calling convention was added in go 1.17 and 1.18. https://go.dev/doc/go1.17#compiler https://go.dev/doc/go1.17#compiler https://go.dev/doc/go1.18#compiler https://go.dev/doc/go1.18#compiler https://go.googlesource.com/proposal/+/master/design/40724-register-calling.md https://go.googlesource.com/proposal/+/master/design/40724-r...
Thaxll 2y ago
I've seen Go code faster than Rust one, for example there was an interesting article years ago about counting words in a file: https://benhoyt.com/writings/count-words/ https://benhoyt.com/writings/count-words/
- silisili 2y ago
  Maybe I'm still asleep, but can anyone who read this explain this part - map[string]*int instead of map[string]int so we only have to allocate once per unique word.
  - jamamp 2y ago
    I believe this is because the code `counts[word]++` basically works by: 1. Hash word, retrieve the value from the counts map 2. Increment the value 3. Hash word, store the value into the counts map By change counts to a map of strings to pointers of ints, you only need to perform #3 once per unique word. Once you've read the int pointer, you need only write to the pointer and not re-hash the word and write that to the map, which can be expensive. https://github.com/benhoyt/countwords/blob/master/optimized.go#L66 https://github.com/benhoyt/countwords/blob/master/optimized....
    - silisili 2y ago
      Ah of course, the allocation is in the map setting work not the integer itself. That makes sense, thanks!
    - kbolino 2y ago
      I am surprised this doesn't get optimized by the compiler. I assume this is necessary in the general case (map could be modified concurrently, causing the bucket for the key to move) but it obviously isn't here.
- kbolino 2y ago
  Anything nontrivial with a map in Rust is surprisingly tricky. I didn't know there were performance implications though.

kbolino 2y ago

I should clarify that by "optimized" I meant hand optimized, not just compiler optimized. You can easily code yourself into surprisingly poor performance with Go, though usually for the same/similar reasons as C#/Java. Rust makes it a little harder to get into the same situations though it's by no means impossible. As to the zero/low-cost abstractions, Go has very few abstractions at a language level and that is what I meant by "much less expressive". If you try too hard to write Go as though it were another language, you will shoot yourself in the foot. However the Go compiler, standard library, and broader ecosystem have come a long way and enable very similar performance profiles to most other compiled languages. It has not been my experience, at least in micro-benchmarks, to see any major performance differences in Go vs e.g. C on things like encryption, hashing, RNG, SIMD, etc. You do need to avoid allocations in hot code paths but that's true of any garbage-collected language. The outstanding performance issues I'm aware of are around deferring, calling methods through an interface, and calling out to cgo. These are pretty minor in most situations but can eat up a lot of CPU cycles if done often in tight loops. They've also been getting better over time and can sometimes be optimized away with PGO.

neonsunset 2y ago
This is fair but performant data processing in Go simply has much lower performance ceiling than Rust, C#, Swift or C++. Which is why all standard library routines that do so (text search, hashing, encryption, etc.) are written in Go's custom """portable""" ASM dialect. It is unwieldy and has API omissions because it takes this half-assed approach many things in Golang ecosystem do. The closer, and better, example is hand-optimized C# where you still (mostly) write portable and generic code for SIMD routines and they get compiled to almost the same codegen as hand-intrinsified C++. I understand where this belief comes from, but the industry at large does itself a huge disservice by tunnel visioning at a handful of (mostly subpar) technologies.
- Thaxll 2y ago
  I think you over hype c# and swift, we did benchmark a grpc api server in c# ( net core ) and Go, same implementation in both languages and Go while faster was using way less memory.
  - neonsunset 2y ago
    Was that with .NET 8? There have been significant performance improvements with each subsequent version in the last 5 years.
- kbolino 2y ago
  Unfortunately, you are right that SIMD support in Go isn't great and basically requires writing platform-specific code in their quirky assembly language or using a third-party library which does that for you. I don't think the existing use of assembly under the hood to accelerate performance when possible is something to be frowned upon though. It's an implementation detail that almost never matters. One issue with the performance of their assembly code though is that it passes arguments and return values on the stack. I saw something about allowing code to use registers instead but I don't think it's available yet.
  - meling 2y ago
    Support for register-based calling convention was added in go 1.17 and 1.18. https://go.dev/doc/go1.17#compiler https://go.dev/doc/go1.17#compiler https://go.dev/doc/go1.18#compiler https://go.dev/doc/go1.18#compiler https://go.googlesource.com/proposal/+/master/design/40724-register-calling.md https://go.googlesource.com/proposal/+/master/design/40724-r...

Thaxll 2y ago

I've seen Go code faster than Rust one, for example there was an interesting article years ago about counting words in a file: https://benhoyt.com/writings/count-words/ https://benhoyt.com/writings/count-words/

silisili 2y ago
Maybe I'm still asleep, but can anyone who read this explain this part - map[string]*int instead of map[string]int so we only have to allocate once per unique word.
- jamamp 2y ago
  I believe this is because the code `counts[word]++` basically works by: 1. Hash word, retrieve the value from the counts map 2. Increment the value 3. Hash word, store the value into the counts map By change counts to a map of strings to pointers of ints, you only need to perform #3 once per unique word. Once you've read the int pointer, you need only write to the pointer and not re-hash the word and write that to the map, which can be expensive. https://github.com/benhoyt/countwords/blob/master/optimized.go#L66 https://github.com/benhoyt/countwords/blob/master/optimized....
  - silisili 2y ago
    Ah of course, the allocation is in the map setting work not the integer itself. That makes sense, thanks!
  - kbolino 2y ago
    I am surprised this doesn't get optimized by the compiler. I assume this is necessary in the general case (map could be modified concurrently, causing the bucket for the key to move) but it obviously isn't here.
kbolino 2y ago
Anything nontrivial with a map in Rust is surprisingly tricky. I didn't know there were performance implications though.