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

101–110 of 209 posts

Re: Rust programs versus Go

#101

Post by burntsushi »

tex0 wrote: post #22
weavie wrote: post #13

Earlier quoted context omitted.

Go seems to perform really poorly in the regex-redux. Against both Node and Python Go is way faster (as one would expect) apart from with the regex-redux.. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Does Go just suck with it's regex performance? Would this be easy to fix by just pulling in a C regex library?

The benchmark is using some third party PCRE lib. This is probably necessary because Go's RE2 lacks some features, but it's not a good comparison.

> This is probably necessary because Go's RE2 lacks some features

No, it's because PCRE is faster than Go's standard library regex engine on this particular benchmark. There is another entry for Go (called just `Go` I believe) that uses Go's "regexp" package.

The regexredux benchmark itself does not require any "fancy" features. It can be satisfied by pure regular expressions.

Re: Rust programs versus Go

#102

Post by flavio81 »

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…

   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.

Re: Rust programs versus Go

#103

Post by notheguyouthink »

Tade0 wrote: post #85

Even though Rust apparently "won" here(does anybody really win in such comparisons?) I don't care that much about it, because I don't consider this the main appeal of the language. It's the compiler error messages, memory safety and the lack of a Garbage Collector that speak to me more than raw performance.

> Even though Rust apparently "won" here(does anybody really win in such comparisons?) I don't care that much about it, because I don't consider this the main appeal of the language.

Completely agree. For me, my primary consideration is developer sanity. A subtle compromise between speed, ease, and clarity. I don't program in Node or Python anymore because while it has ease, clarity is completely missing. I used Rust for 6 months or so and while it has speed and clarity, the ease was just not there for me. Go hits a nice sweet spot for me.

I think if Rust managed to improve ergonomics more and more it would really nail the sweet spot. But, there's still work to do.

Re: Rust programs versus Go

#104

Post by jerf »

ysleepy wrote: post #27

I would be interested in results of go-llvm - measuring some proxy of the intrinsic overhead due to the design choices of go vs. rusts focus on zero-cost abstractions. The clean-room compiler backend of go has some usability advantages, but sacrifices the sort of comprehensive optimization that llvm does.

I haven't heard anybody claim that go-llvm is much faster systematically. I'm assuming that I would have by now. Similarly, the gogcc implementation doesn't seem to have any speed advantages, because again, I assume I would have heard of them by now.

The Rust team has some really interesting blog posts about how you can't just wave LLVM at a program and expect the optimizer to work magic, but that you need to process the code for LLVM first, such as this one: https://blog.rust-lang.org/2016/04/19/MIR.html Bear in mind that not only is the little paragraph about LLVM optimization relevant to my point here, the entire blog post is ultimately about the things the Rust compiler can do that the LLVM optimizer could not; if LLVM just optimized the code magically perfectly, MIR either never would have happened, or would have happened later because the pressures to create it would be less if LLVM was already as optimal as possible.

Re: Rust programs versus Go

#105

Post by skywhopper »

chatmasta wrote: post #46
dullgiulio wrote: post #33

Oh no, not The Benchmarks Game again :( This whole thing is meaningless and deeply flawed. The sources of the various solutions vary a lot in quality: different libraries are used, different settings (in Go vs Java the use of threads is almost never the same). I suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. Can we stop posting them?

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 regex engine can do (specific patterns may influence the results greatly—there are some very simple patterns that send the default Java regex engine into O(n^n) fits). And regex in particular is a very well understood problem space. So something very interesting is going on there for the golang result to be so far off. What is happening? Well, we’ll never know from this page. Oh well?

Re: Rust programs versus Go

#106

Post by [deleted] »

tex0 wrote: post #22
weavie wrote: post #13

Earlier quoted context omitted.

Go seems to perform really poorly in the regex-redux. Against both Node and Python Go is way faster (as one would expect) apart from with the regex-redux.. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Does Go just suck with it's regex performance? Would this be easy to fix by just pulling in a C regex library?

The benchmark is using some third party PCRE lib. This is probably necessary because Go's RE2 lacks some features, but it's not a good comparison.

[deleted]

Re: Rust programs versus Go

#107

Post by vanderZwan »

naasking wrote: post #100
cdoxsey wrote: post #74

Earlier quoted context omitted.

I find microbenchmarks mostly useless. There are just too many variables in play. Also they tend to focus on the developer who optimizes code, not the journeyman developer in your company who actually writes code. C or Fortran looks fantastic on benchmarks, but if you forced all your developers to use C I doubt you'd see a similar outcome. They seem to push developers in the direction of coming up with simple rules o…

I think you'll find the performance per gzipped line of code is a decently robust metric for a performance/productivity tradeoff, although it may have a wide variance. Performance optimizations tend to involve a lot of specialization, which means more code, which makes this ratio worse. The gzipped size is a proxy for the minimum description length/Kolmogorov complexity, which measures language expressiveness.

APL and co kind of undermine that metric, wouldn't you say?

Re: Rust programs versus Go

#108

Post by rwj »

cdoxsey wrote: post #74
glangdale wrote: post #61

Earlier quoted context omitted.

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…

I find microbenchmarks mostly useless. There are just too many variables in play. Also they tend to focus on the developer who optimizes code, not the journeyman developer in your company who actually writes code. C or Fortran looks fantastic on benchmarks, but if you forced all your developers to use C I doubt you'd see a similar outcome. They seem to push developers in the direction of coming up with simple rules o…

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)?

Re: Rust programs versus Go

#109

Post by [deleted] »

notheguyouthink wrote: post #99
egnehots wrote: post #4

simplicity source brain load Rust 95% Go 23%

Sidenote, appending to that list, my NodeJS "brain load" was insane. When I switched from Node -> Go ages ago it was night and day. Funnily, in some scenarios, I find Rust to be less of a brain load than Go. In others, Rust is way way worse. As I mentioned in another post, we use Go to get shit done. I hope Rust can take that mantel some day.

[deleted]

Re: Rust programs versus Go

#110

Post by vanderZwan »

some_account wrote: post #51
dullgiulio wrote: post #33

Oh no, not The Benchmarks Game again :( This whole thing is meaningless and deeply flawed. The sources of the various solutions vary a lot in quality: different libraries are used, different settings (in Go vs Java the use of threads is almost never the same). I suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. Can we stop posting them?

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? :)

Yes, benchmarks are important, which is why we should use proper ones. The Benchmarks Game is not one of those.
Post reply on HN