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

151–160 of 209 posts

Re: Rust programs versus Go

#151

Post by steveklabnik »

Const-me wrote: post #124
v_lisivka wrote: post #15

Earlier quoted context omitted.

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.

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 compilers do, it’s legal for them to use them.

This generally means that C and C++ have a bit more leeway to use less stable/standard things. I think that’s a fine rule, given how the different languages work, but it’s a good example of how tricky all of this is.

[1]: https://doc.rust-lang.org/beta/core/arch/x86/fn._mm_cvtpd_ps... and https://doc.rust-lang.org/beta/core/arch/x86_64/fn._mm_cvtpd...

Re: Rust programs versus Go

#152

Post by steveklabnik »

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…

A while back, there was some stuff about Rust and HashMaps and things. It ended up with this comment: https://www.reddit.com/r/rust/comments/5rwwrv/chashmap_effic...

I don't know if that policy has changed in the last year, but last I heard, that's the rules regarding this.

My understanding is that the intention is to use what's usual in each language.

Re: Rust programs versus Go

#153

Post by steveklabnik »

vertex-four wrote: post #134
vanderZwan wrote: post #128

Earlier quoted context omitted.

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!

I doubt Rust will ever get green threads - it turns out that OS threads are good enough, and futures (async/await) is how IO will get dealt with at scale. Green threads don’t help compute-bound code, so with a solution in place for IO, they’re unnecessary.

It's quite unlikely that Rust the language will get green threads, yes. We are getting stackless couroutines ("generators"), which are related but not the same thing.

There's a ton of options in this space, and they're all slightly different, with different tradeoffs, so it's really hard to make good comparisons. You have to deeply understand exactly what each language is doing.

Re: Rust programs versus Go

#154

Post by forgot-my-pw »

notheguyouthink wrote: post #96
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 really, really like Rust. Yet, I use Go. This is mainly do to firstly, Go just fits way way better for my shop. The transition from my fellow employees from Python to Go is pretty straight forward. Secondly, Go is just nicely setup for ease. I had so much hell in Rust cross compiling a simple https server.. it was mind numbing. It might be better now, but I was shocked at how difficult it was. Finally, Go is just m…

Right tool for the right job.

Re: Rust programs versus Go

#155

Post by PSeitz »

kjeetgill wrote: post #127
PSeitz wrote: post #88

Earlier quoted context omitted.

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.

The performance comparisons between gc and non-gc languages show otherwise. Also, memory consumption eventually costs cpu cycles.

Re: Rust programs versus Go

#157

Post by benmmurphy »

Thaxll wrote: post #125
_Codemonkeyism wrote: post #40

Why is Java faster than Go?

Java is not faster than Go. Edit: Why I'm beeing downvoted, this very much benchmark linked show that Go is faster than Java in most scenarios: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

if you look at how the benchmarks run i suspect they would disadvantage java. java is known for having slow startup times and also an optimising JIT that takes a while to kick in. go is definitely going to be faster for some command line application that takes 20s to run but if you have a long running process i think it will be much closer.

Re: Rust programs versus Go

#158

Post by kjeetgill »

PSeitz wrote: post #155
kjeetgill wrote: post #127

Earlier quoted context omitted.

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.

The performance comparisons between gc and non-gc languages show otherwise. Also, memory consumption eventually costs cpu cycles.

I'm not really disagreeing with you, performance comparisons between gc and non-gc languages DO tend show otherwise, but consider this: a common GC strategy in C++ is arena allocation. Faster allocations and deallocations but more memory overhead. It's still C++ but a little faster in the right situation.

Re: Rust programs versus Go

#159

Post by Aissen »

Aissen wrote: post #143
burntsushi wrote: post #137

Earlier quoted context omitted.

I had fun with this: [andrew@Cheetah benchgame] time bench-native For comparison, this is the timing for the Rust program, unchanged from the benchmark site: $ time ./target/release/bench-rust-regex See https://gist.github.com/BurntSushi/9d35258444fda83de208d31fd... for source code and full results. And no, I won't submit this myself, although I would find it absolutely hilarious if someone did and managed to get it…

Awesome work, thanks !

This looked fun, so I did my own micro-benchmark on an rpi3, armv7 :

        $ for i in bench-native bench-pcre bench-pcrejit bench-rure; do echo -n $i; (cd $i; time ./$i  /dev/null) ; echo; done
        bench-native
        real    0m24,883s
        user    0m56,580s
        sys     0m0,120s

        bench-pcre
        real    0m13,125s
        user    0m27,200s
        sys     0m0,160s

        bench-pcrejit
        real    0m2,688s
        user    0m3,140s
        sys     0m0,120s

        bench-rure
        real    0m2,779s
        user    0m3,300s
        sys     0m0,090s
It looks like pcre with JIT enabled is always faster than the rure version, but this is very close.

Re: Rust programs versus Go

#160

Post by PopsiclePete »

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.

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.

Post reply on HN