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

121–130 of 209 posts

Re: Rust programs versus Go

#121

Post by jcranmer »

rwj wrote: post #108
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 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 have to make sure that you're not embarking on a journey of overfitting your benchmark suite. Microbenchmarks, where you look at a single kernel in isolation, are extremely hard to get right, especially because it can be easy to accidentally test how fast your computer can do nothing.

Benchmarks can be incredibly useful, but an uncurated, gamified set of benchmarks are not going to be in the category of useful benchmarks. There is a risk that by turning a bad benchmark into a programming mantra, you can seriously harm the performance of your code in the future (Duff's device and object pooling are two "optimization" strategies that are now more harmful to your performance than not doing them).

Re: Rust programs versus Go

#122

Post by Thaxll »

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.

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

Re: Rust programs versus Go

#123

Post by simias »

PSeitz wrote: post #88
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.

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 often thinking "uh, I don't know when I won't be needing this resource anymore, thankfully the GC will figure that out for me"? Because I certainly never do. Either the resource is scoped and I expect it to be destroyed at the end of a certain block RAII-style, or it's some longer-lived resource (connection handle, object in a videogame, Window object in a GUI) that I'm going to store in some container and destroy when I no longer need it. If I have multiple references and a complex dependency graph I might use a reference counted container which is effectively a very simplistic GC but it's the exception and not the rule and it's still completely transparent and easy to reason about.

I never, ever, feel like I'm missing a GC when I'm coding in Rust or C++. In C I miss destructors and RAII but that's it. I just don't understand why they're so popular, at best they save you a few lines of cleanup code in your destructors, at worse they make your code behave sub-optimally and non-deterministically because you don't know when your objects are going to be destroyed and your destructors are going to run. Then if you need to write critical code you have to carefully step around the GC to be sure that your perf will be deterministic.

I genuinely don't get GCs.

Re: Rust programs versus Go

#124

Post by Const-me »

v_lisivka wrote: post #15
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…

C/C++ are cheating by using Intel specific instructions, like _mm_cvtpd_ps. I.e. they are with hardware-specific acceleration. If standard library will be used instead, or if Rust code will be updated to use same instructions, we will see different results.

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.

Re: Rust programs versus Go

#126

Post by Thaxll »

This week there was a popular benchmark about implementing a treap in various languages, Go was as fast as both Rust version and c++ with shared pointer. It was even faster than those languages on some other platforms.

So yeah benchmark ...

https://github.com/frol/completely-unscientific-benchmarks

Re: Rust programs versus Go

#127

Post by kjeetgill »

PSeitz wrote: post #88
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.

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

There's more to it than that. Having a garbage collector can be faster even, but would you take a faster program if it cost you memory footprint or predictability? It just depends on what you're doing.

Re: Rust programs versus Go

#128

Post by vanderZwan »

notheguyouthink wrote: post #115
vanderZwan wrote: post #111

Earlier quoted context omitted.

> Oh yea, and green threads, god do I wish Rust had green threads. They still don't? I thought they were working on that years ago, no?

They had green threads, but removed it. To my knowledge, there are multiple libraries that effectively implement green threads, but it's still a work in progress. Might be production ready, not sure, but I believe at the very least the ergonomics are a work in progress.

Hmm, sounds like the kind of thing that is hard to get right then. Maybe it's for the best that it isn't in the standard library until the design and implementation stabilises then.

Sucks for early adopters though!

Re: Rust programs versus Go

#129

Post by [deleted] »

Thaxll wrote: post #119
giancarlostoro wrote: post #50

Earlier quoted context omitted.

I used to like Go a bit, but never did a full blown application in it, just did enough to get a feel of it. Having tried Rust recently (after not liking the idea of not having classes like in Go) I have to say I prefer Rust for several reasons. For starters the tooling for Rust is well done. If I want to install Rust on any machine I'm on I just go to https://rustup.rs/ and go from there, then I can use rustup to upd…

You mention tooling and IDE where Go is better than Rust in that space and as for Cargo just use go dep problem solved.

[deleted]

Re: Rust programs versus Go

#130

Post by logicallee »

sagichmal wrote: post #35
logicallee wrote: post #28

Earlier quoted context omitted.

to be fair, it was explicitly designed to be a systems language, and its specification says "Go is a general-purpose language designed with systems programming in mind." This should be removed, and I would say that it gave up on its design goal of being a systems language.

"Systems programming language" has multiple, equally-valid definitions. This no-true-Scotsman rules lawyering about language classification is the least interesting possible discussion about a programming language.

you're right it's not an interesting semantic distinction, but it's weird to have people going around saying "but it is not (and does not intend to be) a systems language" when it's an explicit design goal for Go and explicitly mentioned in line 1 of its specifications. OK, not a very interesting discussion.
Post reply on HN