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

161–170 of 209 posts

Re: Rust programs versus Go

#161

Post by Const-me »

steveklabnik wrote: post #151
Const-me wrote: post #124

Earlier quoted context omitted.

That instruction is SSE2. SSE2 instruction set is guaranteed to be supported on all x86-64 CPUs, be it Intel, AMD or VIA. Similarly, the intrinsics are supported by all modern C and C++ compilers for decades already. Some compilers even generate SSE code by default for code like double x = 42.0 * y, in place of older x87 floating point instructions. x87 code is slower, and has multiple numerical stability issues.

A lot of this depends on the rules. For example, rust (rightfully) cannot use nightly, and unstable features. If it could, you could use these too. Rust will have these in the next stable release[1], so we’ll see after that ships! These intrinsics aren’t part of the C or C++ languages, but compilers provide their own, so it’s sorta like a language extension. Since they don’t use the same stability model Rust compiler…

> C and C++ have a bit more leeway to use less stable/standard things

Here’s a link to the GCC header from 2002 that includes that _mm_cvtpd_ps intrinsic: https://github.com/gcc-mirror/gcc/commit/d3ceaee1b851570b269...

If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability.

About standardization… I don’t think the fact that ISO has standardized some parts of the language but not other is hugely important. For example, by the time when ISO has adopted large parts of STL into the new standard, there was already a consensus in the industry that STL is the standard library.

Re: Rust programs versus Go

#162

Post by PopsiclePete »

flavio81 wrote: post #102
Tuna-Fish wrote: post #62

Earlier quoted context omitted.

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.

Before you do that, you might want to research GC 'throughput' vs GC 'latency'. Go chose to optimize for latency, not throughput. And for very good reasons.

Re: Rust programs versus Go

#163

Post by PopsiclePete »

rqs wrote: post #39
cmyr wrote: post #10

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/...

Go makes writing networking services like a dream for sure, and Rust also seems have it's own plan[0] on network service field. It could be awesome to see they compete with each other and come up something good. [0] https://internals.rust-lang.org/t/announcing-the-network-ser...

Rust is still figuring out its "async" story. Go figured it out, and went full steam ahead before the language was even made public - day 0, basically.

I'm not holding my breath for Rust dethroning non-perf-critical Go projects anytime soon.

Re: Rust programs versus Go

#164

Post by steveklabnik »

Const-me wrote: post #161
steveklabnik wrote: post #151

Earlier quoted context omitted.

A lot of this depends on the rules. For example, rust (rightfully) cannot use nightly, and unstable features. If it could, you could use these too. Rust will have these in the next stable release[1], so we’ll see after that ships! These intrinsics aren’t part of the C or C++ languages, but compilers provide their own, so it’s sorta like a language extension. Since they don’t use the same stability model Rust compiler…

> C and C++ have a bit more leeway to use less stable/standard things Here’s a link to the GCC header from 2002 that includes that _mm_cvtpd_ps intrinsic: https://github.com/gcc-mirror/gcc/commit/d3ceaee1b851570b269... If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability. About standardization… I don’t think the fact that ISO has standardized some parts of…

> If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability.

That's not what I'm saying, to be clear. What I'm saying is this:

> I don’t think the fact that ISO has standardized some parts of the language but not other is hugely important.

This is very true for C and C++, but less true for Rust. This means that, depending on how you define the rules, certain things are allowed or disallowed. Rust provides that exact same header, yet isn't allowed to use it. Rust is effectively limited to "what's in the standard," whereas C and C++ are not.

I think that the rules the way they are makes perfect sense. I'm not trying to complain one or the other is hobbled here. I'm trying to point out how language differences can matter when trying to come up with good benchmarks.

Re: Rust programs versus Go

#165

Post by PopsiclePete »

ashleyn wrote: post #78
boyter wrote: post #25

Not really that surprising. I spent a good chunk of time trying to make a Go program as fast as a well written Rust one (tokei) which I wrote about here https://boyter.org/posts/sloc-cloc-code/ and in the end the GC was what held me back. I suspect its possible to get Go programs for the most part close to the performance of Rust but in the end the lower level and fewer abstractions mean a well written Rust or C/C++…

GC at the systems level is an idea that has had its chance. 40 something years out, and we all mostly use C, with Rust being the only contender to knock it off its perch. It's probably time to give up the dream; GC is only good if you're willing to assume the always-moderate cost of its implementation, relegating it to scripting languages.

Go doesn't really play in the "systems level" field all that much, tho. They even removed the "systems" bit from the Go home page.

Go doesn't compete with C, unless C was the wrong choice to begin with. Nobody is writing an OS in Go. It competes with Python and Node.

I've reduced my Python/Node code by roughly 92.5% after Go reached 1.0 and I couldn't be happier.

Re: Rust programs versus Go

#166

Post by steveklabnik »

PopsiclePete wrote: post #160
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.

No reason to learn Rust or Go - learn Rust and Go. I use Go for most "network service" type stuff at my job. I would probably not choose Rust for those, even if I was as comfortable with it as I was with Go (which I'm not, since Go is much, much simpler). There's many variables when considering what language to pick for a problem and if speed was the only thing we cared about, we'd just do raw assembly always.

We're even seeing production deployments that combine the two directly; Conduit and Dropbox both come to mind.

Re: Rust programs versus Go

#167

Post by PopsiclePete »

simias wrote: post #123
PSeitz wrote: post #88

Earlier quoted context omitted.

Garbage collector is actually something you'd want, if it caused no performance hit.

Meh. I might have a huge Stockholm syndrome with manual resource management since I've basically started coding with C and used GC-free languages for most of my life since them but I never really understood why people liked GCs so much outside of scripting languages where convenience trumps correctness and you just litter your resources around instead of tracking them properly. Are people using GC languages really of…

I'm guessing you've never written heavily concurrent code.

C/C++/Rust are totally fine when you have a single thread. It's concurrency and parallelism where object ownership and who gets to destroy what and when becomes a real problem unless you have GC.

Re: Rust programs versus Go

#168

Post by naasking »

vanderZwan wrote: post #107
naasking wrote: post #100

Earlier quoted context omitted.

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?

Kolmogorov complexity is "ideal compression", in that it bundles the axioms and the expression to reproduce the desired output using those axioms. So it really is a perfect measure for this type of thing.

Gzip is an approximation of this metric of course, and the only flaw in the benchmark suite is that it should really include the size of the runtime which provides the programming language's axioms.

APL is also a good example of why it's important to include various programs in the suite for a valid comparison. Some APL programs are longer than more expressive equivalents when APL is ill-suited to the problem, and once you include the axioms.

Re: Rust programs versus Go

#169

Post by Const-me »

steveklabnik wrote: post #164
Const-me wrote: post #161

Earlier quoted context omitted.

> C and C++ have a bit more leeway to use less stable/standard things Here’s a link to the GCC header from 2002 that includes that _mm_cvtpd_ps intrinsic: https://github.com/gcc-mirror/gcc/commit/d3ceaee1b851570b269... If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability. About standardization… I don’t think the fact that ISO has standardized some parts of…

> If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability. That's not what I'm saying, to be clear. What I'm saying is this: > I don’t think the fact that ISO has standardized some parts of the language but not other is hugely important. This is very true for C and C++, but less true for Rust. This means that, depending on how you define the rules, certain thi…

> This is very true for C and C++, but less true for Rust

Right, Rust has essentially a single implementation, and its standard is written by the developers of that implementation. C++ standard is set by huge international standard-setting body with headquarters in Switzerland.

That’s why authors of Rust specs are doing much better job keeping the spec in sync with the actual language and its libraries.

IMO this difference is mostly about quality of the language standards, but is almost irrelevant to the actual language.

Post reply on HN