4 ms·
While it’s a nice bed time story if you like go, the reality is no, it’s not typical. Go has a good perf story, but typically rust or c++ would be faster after
by wokwokwok 3y ago
While it’s a nice bed time story if you like go, the reality is no, it’s not typical.
Go has a good perf story, but typically rust or c++ would be faster after heavy optimisation; and should be more or less on par with typical applications. This isn’t a critique of go, and shouldn’t surprise anyone.
Typically go also has unexpected optimisation hoops to jump through and problems related to the heavy use of channels (see the well documented answer here: https://stackoverflow.com/questions/47312029/when-should-you-use-a-mutex-over-a-channel https://stackoverflow.com/questions/47312029/when-should-you...), so you would generally expect it to be slower…
…but, naive implementations are always slower, and really, it’s probably much of a muchness out the box for most day to day uses.
In almost all situations (even python or Java) you can get great performance if you invest time and effort in it.
But idiomatic code typically faster than rust? No, not really.
- riku_iki 3y ago> but typically rust or c++ would be faster after heavy optimisation; it is concerning how much digging was required to optimize rust code in this case.
- fredrikholm 3y agoWhilst still being 1/3rd slower than the Go version.
- Filligree 3y agoThey could have used lifetimes. Instead they used elaborate workarounds, which turned out to be slower.
- pigpang 3y agoRust-protobuf is much slower than quick-protobuf or prost.
- v0y4g3r 3y agoThe Go version is not a naive implementation, it's also the well optimized version from VictoriaMetrics.
- sapiogram 3y agoThe Go code is already hyper-optimized by experts, just not by the blog authors, so you don't read about it here. As someone who has tried to write high-performance Go code on occasion, I can assure you that a ton of digging would have been required on that side as well.
- kjksf 3y agoTo bring this discussion back to earth, the Go code in question is: https://github.com/VictoriaMetrics/easyproto/blob/master/reader.go https://github.com/VictoriaMetrics/easyproto/blob/master/rea... I don't see why did you label Aliaksandr Valialkin, the author, an "expert". I mean, he's no dummy but what exactly makes him an expert on optimizing Go code? As someone who also writes Go, I don't see any "hyper optimizations" in the code. It just decodes the bytes of Protocol Buffer using straightforward code that I would expect a competent developer to write. It really is just: read bytes from memory ([]byte) and interpret them according to PB spec. There's only one trick there: unsafeBytesToString() that does no-allocation conversion of []byte to string. This is unsafe in general but safe in their specific case. And I've seen this trick before so it's not some secret, expert-only knowledge. Most comments here are like bad LLMs: hallucinating opinions without bothering to spent even few minutes acquiring the data to base those opinions on.
- sgift 3y ago> I don't see why did you label Aliaksandr Valialkin, the author, an "expert". I mean, he's no dummy but what exactly makes him an expert on optimizing Go code? https://victoriametrics.com/team/ https://victoriametrics.com/team/ - Let's see. Author of multiple performance-optimized libraries with a masters degree in computer software engineering and a background in highly scalable systems (as needed for adtech). Sounds pretty much like an expert for optimizing code to me. > And I've seen this trick before so it's not some secret, expert-only knowledge. So, if you know it it's not export knowledge or what's your argument here?
- kasey_junk 3y agoHe’s probably most well known in the golang community for fasthttp which is a widely used and highly optimized golang replacement for the golang stdlib. I’m a long term golang developer and I think calling him a golang optimization “expert” is fair. That said, I agree with your assessment about this particular code. It’s fairly straightforward idiomatic go.
- pjmlp 3y agoWhile I am not a big Go fan, most people validating Go's performance mix language and implementation, and forget gccgo also exists, sharing many optimizations offered by GCC's backend. Unfortunely, it seems stuck in Go 1.18, the last pre-generics version, with no roadmap for moving forward. Given Go's folks stance on generics, still a lot of Go code is compilable with gccgo.
- kosherhurricane 3y agoIt's really easy to improve the performance of Go implementation as compared to python or Java. There are lots of built-in tools to help you (like the profiler), and the resulting code is really very legible even to fresh college grads. This is based on my first hand experience, but YMMV.