3 ms·
I should clarify that by "optimized" I meant hand optimized, not just compiler optimized. You can easily code yourself into surprisingly poor performance with G
by 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 agoThis 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 agoI 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 agoWas that with .NET 8? There have been significant performance improvements with each subsequent version in the last 5 years.
- kbolino 2y agoUnfortunately, 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 agoSupport 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...