Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust programs versus Go

benchmarksgame-team.pages.debian.net

Post reply on HN
Print view View original

191–200 of 209 posts

Re: Rust programs versus Go

#191

Post by igouy »

cdoxsey wrote: post #41

These benchmarks have many flaws. Consider this thread: https://www.reddit.com/r/golang/comments/51mhzv/on_the_binar... The binary-trees benchmark would fare significantly better in Go if it were allowed to use an arena allocator like other implementations. But its not. This despite the fact that the Rust version literally uses one: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . I guess because its…

>> Go if it were allowed to use an arena allocator

Go is allowed to use an arena allocator.

>> I guess because its not in the stdlib in Go?

A popular third-party library implementation would be fine.

For example, couchbase/go-slab except that it doesn't seem to be a live project and there's no indication that it is actually used by the Go community.

>> so does C use malloc?

C using malloc -- https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Rust programs versus Go

#192

Post by igouy »

glangdale wrote: post #61
cdoxsey wrote: post #41

These benchmarks have many flaws. Consider this thread: https://www.reddit.com/r/golang/comments/51mhzv/on_the_binar... The binary-trees benchmark would fare significantly better in Go if it were allowed to use an arena allocator like other implementations. But its not. This despite the fact that the Rust version literally uses one: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . I guess because its…

There are many predictable things in life: the tendency of up-and-comer languages to blitz these benchmarks due to careful optimization, and the tendency of people whose pet language has lost on a benchmark or two to get on here and write off the idea that anyone should ever benchmark cross-language. Some of the benchmarks are pretty ridiculous and flawed. Others look pretty straightforwardly comparable. I have troub…

>> the regex one is a absolute festival of 'who brought a fast regex library to the gunfight'

Yes performant libraries are important.

Re: Rust programs versus Go

#193

Post by igouy »

jcranmer wrote: post #121
rwj wrote: post #108

Earlier quoted context omitted.

I always find this argument really strange. How is making a complicated decision (which language is best for this task) easier using less information (the benchmarks are only one facet of the decision)?

The name of the website used to be the language shootout; it was subsequently changed to be called the benchmarks game to emphasize that its not a rigorous comparison between languages. Benchmarking is hard. You have to identify workloads that are realistic and representative, large enough to be sure you're hitting the steady-state performance yet small enough you can run them on a regular basis. And, of course, you…

nit-pick -- The name was changed after the Virginia Tech shooting, because the search results were mostly about gun deaths and porn. Not a bright happy start to my day.

Not "to emphasize" just about the benchmarks game, but more generally about cross-language comparisons -- and I had to pick a name ;-)

Re: Rust programs versus Go

#194

Post by igouy »

MikkoFinell wrote: post #81
masklinn wrote: post #68

Earlier quoted context omitted.

> Nobody is stopping Golang enthusiasts from posting the results with a slab allocator or some other third-party packages. You've never witnessed the "game"'s maintainer interacting with people have you?

What is it like?

For example,

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

Re: Rust programs versus Go

#195

Post by igouy »

cdoxsey wrote: post #66
dvfjsdhgfv wrote: post #60

Earlier quoted context omitted.

> I guess because its not in the stdlib in Go? It's a game, and the sources are available. Nobody is stopping Golang enthusiasts from posting the results with a slab allocator or some other third-party packages.

Yes the maintainer is. People have tried.

Which popular third-party Go slab-allocator or arena allocator was used?

Re: Rust programs versus Go

#196

Post by igouy »

skywhopper wrote: post #105
chatmasta wrote: post #46

Earlier quoted context omitted.

I’m the OP. I figured this post would either get tons of upvotes or flagged off the first page. The title really is a firebomb on HN lol. But honestly I find it genuinely interesting. I’m planning to take some time to learn either rust or go this month, so comparisons like this are helpful for me. And I also appreciate the contrarian comments and discussion of the merits (or lack thereof) of the benchmarks.

I disagree that the comparison as presented on this page is useful for you. If there were any context or discussion of the results and what they mean in terms of differences between the languages, then maybe it could be. But raw benchmarks collected with no indication of why or how is not. In the regex test, for example, all the patterns are very similar to each other and don’t really cover the breadth of what a rege…

>> Well, we’ll never know from this page.

Apparently, you now know that there's "something very interesting" to investigate! So, investigate?

Re: Rust programs versus Go

#197

Post by igouy »

_ph_ wrote: post #56
some_account wrote: post #51

Earlier quoted context omitted.

Benchmarks are important actually. Maybe they are not 100% accurate but they do tell you that rust is faster than go. Since rust is also more complex than go, you have to decide if it's worth complexity and learning curve for the speed. Without benchmarks, we all would use python for everything right? :)

Well, no. Some of the presented benchmarks prevent the Go solution to be as efficient as the Rust one by their rules, e.g. prohibiting object pools in Go, but not in other languages. Same with hash tables. They benchmark the default Go hash tables vs. custom implemented ones for the benchmark in C.

No, a "custom implemented" hash table is not used for the benchmark in C.

A generic hash table from a third-party library is used -- something written to be generally useful, not compromised to look good on a toy benchmark.

https://github.com/attractivechaos/klib/

Re: Rust programs versus Go

#198

Post by igouy »

Tuna-Fish wrote: post #62
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…

Explanations for the few largest offenders: 1. regex-redux Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it. (And has no sheer perfomance cliffs where a carefully crafted target string or search expression can DOS the app.) Also, I think the rust implementation can do less copying. GO just uses PCRE. (Which is weird, isn't RE2 a google project?) 2. binary…

>> GO just uses PCRE

Currently, there are 4 Go regex-redux programs and 2 use PCRE.

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

>> The GO implementation has to use the platform allocator

… because there doesn't seem to be a Go third-party or stdlib arena allocator.

Re: Rust programs versus Go

#199

Post by igouy »

Thaxll wrote: post #122
flavio81 wrote: post #102

Earlier quoted context omitted.

binary-trees source secs Go 28.80 Lisp 8.49 You know what I would choose if I needed a garbage collected language. Btw,the lisp version uses no fancy tree allocator, just plain standard lisp lists.

And yet Go is much faster than Lisp, you shouldn't look at that specific Benchmark.

You should look where the time goes in your app.

Re: Rust programs versus Go

#200

Post by igouy »

slezyr wrote: post #43
codetrotter wrote: post #29

Earlier quoted context omitted.

> > the results are much more similar Parent is talking about performance, not source code

True, but that performance gained by writing code in a way which most devs wouldn't do.

I very much doubt that you actually know what most devs would do.
Post reply on HN