4 ms·
I agree with rsc about that study having problems, [1] but I'm not sure this part is accurate: > Second, the summary of the Discord post about switching from G
by scottlamb 5y ago
I agree with rsc about that study having problems, [1] but I'm not sure this part is accurate:
> Second, the summary of the Discord post about switching from Go to Rust is incredibly misleading. The original Discord post showed a single graph plotting both a Go server and the equivalent Rust server. The Rust line had more predictable performance and avoided the latency spikes in the Go line, but the lines were roughly comparable. Instead, the AWS post displayed the Go graph next to a graph of the Rust server after a significant rewrite to use new data structures and more RAM, circling “ms” vs “µs” time scales. This is either a complete misunderstanding of the Discord post or blatant dishonesty.
The discord post [2] says this:
> After the service ran successfully for a few days, we decided it was time to re-raise the LRU cache capacity. In the Go version, as mentioned above, raising the cap of the LRU cache resulted in longer garbage collections. We no longer had to deal with garbage collection, so we figured we could raise the cap of the cache and get even better performance. We increased the memory capacity for the boxes, optimized the data structure to use even less memory (for fun), and increased the cache capacity to 8 million Read States.
He paraphrased "optimized the data structures to use even less memory (for fun)" as "a significant rewrite to use new data structures". The post doesn't say how involved the optimization was, but I got the impression it might have been pretty trivial to shave a few bytes off the most common allocation or some such.
And as for increasing the cache capacity, that's something Rust allowed them to do without problems but Go 1.10 didn't, so I think it's entirely fair to include it in the comparison. Maybe Go 1.18 would also have been able to do this, but unless Discord dusts off their old server to aid people choosing a language in 2022, we're not going to really know...
[1] and even made a similar argument here: https://news.ycombinator.com/item?id=30313943 https://news.ycombinator.com/item?id=30313943
[2] https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to...
- Mathnerd314 5y agoThe Discord and AWS posts are both about GC vs no GC. The GC in Go prevented scaling the cache due to latency spikes. Rust doesn't have a GC and so the cache could be grown from x million to 8 million without increasing latency. The Discord post says just simply rewriting the service from Go to Rust increased performance in all metrics (but doesn't give numbers). But Discord also made other changes during the rewrite - changing from hash table to B-tree, data structure layout optimizations, reducing memory copying, etc. And the graphs are with those changes included. So the Discord graphs aren't a pure Rust vs Go comparison. I guess I can agree with rsc that it's "misleading" to cite the graphs during a Rust vs. Go comparison. But the headings of the Discord post imply the latency change for average response time from milliseconds to microseconds is purely due to increasing the cache size, which was only possible due to eliminating the GC spikes. So it is fair to include that as an issue in a Go 1.10 vs Rust comparison. rsc's opinion seems to be that Go 1.18 will fix the latency issue - I disagree, but the only way to tell is to redo the measurements.
- scottlamb 5y agoSwitching from hash table to B-tree is another example of something Rust is good at and Go 1.10 wasn't, so I'd call it a fair part of the comparison. That version of Go doesn't have generics, so you're stuck with the builtin hash tables, reflection, or code duplication/generation. (Also, I'm reading the post correctly, this switch was included in the first set of graphs that he called "roughly comparable"). I've never seen a "we switched program $X from language $Y to language $Z" post that reproduced exactly the same program, and I don't think it's reasonable to expect that. This one doesn't seem to have done anything crazy like a completely different algorithm, SIMD intrinsics replacing naive code, etc. (The Game's programs actually are that different, so I don't like that study at all.)
- igouy 5y ago> SIMD intrinsics replacing naive code The programs that use SIMD intrinsics are split-out: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html#below https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- fulafel 5y agoNitpick: Rust comes with GC in the std lib: https://doc.rust-lang.org/book/ch15-04-rc.html https://doc.rust-lang.org/book/ch15-04-rc.html