Rust programs versus Go

#1

Post by chatmasta » Wed, May 16, 2018, 8:47 AM UTC

Rust programs versus Go
benchmarksgame-team.pages.debian.net

Re: Rust programs versus Go

#2

Post by CodinM » Wed, May 16, 2018, 9:27 AM UTC

whoa

Re: Rust programs versus Go

#3

Post by simias » Wed, May 16, 2018, 9:29 AM UTC

I expect Rust to be faster than Go as a rule because of its somewhat lower level nature and cost-less "unmanaged" abstractions but I didn't expect it to be a full order of magnitude faster than Go for some benchmarks. Are the Go snippets not properly optimized or is there something else going on?

I think pitting Go against Rust is somewhat inflammatory but if you look at the Rust vs. C++ benchmark the results are much more similar: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... so clearly it's not Rust doing something right, it's the Go implementation doing something wrong. Actually even Java fares (mostly) better: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Rust programs versus Go

#4

Post by egnehots » Wed, May 16, 2018, 9:34 AM UTC

  simplicity

  source      brain load
  Rust        95%
  Go          23%

Re: Rust programs versus Go

#5

Post by [deleted] » Wed, May 16, 2018, 9:34 AM UTC

[deleted]

Re: Rust programs versus Go

#6

Post by 1125 » Wed, May 16, 2018, 9:34 AM UTC

They're sorted by highest delta, which makes it look so significant in the first moment.

Also, though one of golangs target was to get close to c-like performance, they never intended to be the "performance-killer" since the focus is also strong simplicity and productiveness.

More info: https://golang.org/doc/faq#Why_does_Go_perform_badly_on_benc...

Re: Rust programs versus Go

#7

Post by oblio » Wed, May 16, 2018, 9:37 AM UTC

simias wrote: post #3

I expect Rust to be faster than Go as a rule because of its somewhat lower level nature and cost-less "unmanaged" abstractions but I didn't expect it to be a full order of magnitude faster than Go for some benchmarks. Are the Go snippets not properly optimized or is there something else going on? I think pitting Go against Rust is somewhat inflammatory but if you look at the Rust vs. C++ benchmark the results are muc…

The JVM has a ton of work put into it, it wouldn't surprise me if Java is faster than Go for quite a few things.

Re: Rust programs versus Go

#8

Post by simias » Wed, May 16, 2018, 9:37 AM UTC

egnehots wrote: post #4

simplicity source brain load Rust 95% Go 23%

It's true that performance is not always the main metric to consider but in this case I'm not really sure that Go makes that much of a difference. Take the "regex-redux" benchmark for instance, compare the two versions:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I don't find the code complexity obviously worse for the Rust version, yet it runs a full order of magnitude faster in this benchmark.

Re: Rust programs versus Go

#9

Post by jon-wood » Wed, May 16, 2018, 9:39 AM UTC

simias wrote: post #3

I expect Rust to be faster than Go as a rule because of its somewhat lower level nature and cost-less "unmanaged" abstractions but I didn't expect it to be a full order of magnitude faster than Go for some benchmarks. Are the Go snippets not properly optimized or is there something else going on? I think pitting Go against Rust is somewhat inflammatory but if you look at the Rust vs. C++ benchmark the results are muc…

It’s less Go doing something wrong and more just that they do different things. Go has a garbage collector which will naturally slow things down somewhat, while Rust handles memory (de)allocation at compile time.

Re: Rust programs versus Go

#10

Post by cmyr » Wed, May 16, 2018, 9:40 AM UTC

Nothing in these results should really surprise anyone. Go is a good tool for writing networking services, but it is not (and does not intend to be) a systems language.

For another perspective, look at Go versus Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...