16 ms·

Rust programs versus Go

144 points by chatmasta 9y ago

CodinM 9y ago
whoa
simias 9y ago
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 much more similar: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... so clearly it's not Rust doing something right, it's the Go implementation doing something wrong. Actually even Java fares (mostly) better: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- oblio 9y ago
  The JVM has a ton of work put into it, it wouldn't surprise me if Java is faster than Go for quite a few things.
- jon-wood 9y ago
  It’s less Go doing something wrong and more just that they do different things. Go has a garbage collector which will naturally slow things down somewhat, while Rust handles memory (de)allocation at compile time.
  - _ph_ 9y ago
    The problem is, that some of this benchmarks rules prevent the Go solution from using the same efficient code than its competitors, so the numbers are just not valid.
  - hellofunk 9y ago
    > Rust handles memory (de)allocation at compile time You are saying that Rust is doing its runtime memory allocation at compile time? Are you sure you don’t mean compile time management of memory? Two very different different things.
    - notheguyouthink 9y ago
      Isn't one of those impossible? Ie, there's only one reasonable interpretation of that sentence? Not saying being explicit isn't important, just trying to understand you.
      - hellofunk 9y ago
        Yes, what poster commented is in fact impossible.
  - atilaneves 9y ago
    I'm still puzzled by the continued belief that a tracing GC will "naturally slow things down somewhat". Why do you think that's the case?
    - yoklov 9y ago
      You’re forcing the program to rediscover facts about itself at runtime. This is not free. That doesn’t mean a GCed lang is always slower than a lang where memory is managed manually. It means that the theoretically optimal implementation using GC has to do more work than the theoretically optimal implementation that manages its own memory. In the case where the theoretically optimal implementation needs a GC, the unmanaged language could always implement that anyway, but that’s vanishingly rare — typically a GC gets its speedup by using pools, which are also available to unmanaged code.
- slezyr 9y ago
  > Rust vs. C++ benchmark the results are much more similar Not really... Try compare sources of those programs. For example spectral-norm uses OpenMP and other things that make source look really different from the one you would write in real life. Rust program looks much simpler and closer to real life code. https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-rust-4.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-gpp-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - codetrotter 9y ago
    > > the results are much more similar Parent is talking about performance, not source code
    - slezyr 9y ago
      True, but that performance gained by writing code in a way which most devs wouldn't do.
      - igouy 8y ago
        I very much doubt that you actually know what most devs would do.
- v_lisivka 9y ago
  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.
  - p0nce 9y ago
    If you use a LLVM compiler, _mm_cvtpd_ps just translate to LLVM IR and is not Intel specific anymore.
    - giancarlostoro 9y ago
      They're using g++ though, afaik that's just using GCC is it not? But good catch altogether.
  - Const-me 9y ago
    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.
    - steveklabnik 9y ago
      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.html 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_ps.html https://doc.rust-lang.org/beta/core/arch/x86_64/fn._mm_cvtpd...
- Tuna-Fish 9y ago
  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-trees The benchmark needs to build a massive binary tree. The Rust implementation allocates it's tree in a TypedArena, which is basically a bump allocator for objects that are all dropped simultaneously. It requires very minimal metadata or work per allocation. (Not zero, because it does properly call all destructors.) The GO implementation has to use the platform allocator. The results shouldn't be very surprising... 3. Manderbrot Not sure, but I think the Rust version is designed for autovectorization while the Go one is scalar. After that the Go runtimes are within 2.5x of the Rust ones.
  - Jweb_Guru 9y ago
    > Not zero, because it does properly call all destructors. I believe that there is an optimization that allows this to be completely avoided for types with only trivial or no destructors.
  - pron 9y ago
    > The GO implementation has to use the platform allocator. So does the Java implementation, and still it fares much (3x) better than Go.
    - deleted 9y ago
      [deleted]
    - pcwalton 9y ago
      Because the Java GC has better throughput than the Go GC. The Go GC makes enormous throughput sacrifices by prioritizing latency above all else.
  - burntsushi 9y ago
    With respect to your comments about regex, could you please share with me where you got your information? I would love to know so that I can go bug whoever it is to correct it. > Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it. The only true part of this is that Rust's regex engine lacks many features found in PCRE. Mostly, these features revolve around things that are either impossible or not-known/difficult to add to a linear time implementation in an efficient way. The most popular features among these are backreferences and various types of lookaround. However, it is completely unsubstantiated to say that Rust's regex engine is faster than PCRE. At best, you can say that they are competitive with each other, where one regex engine will do better than the other on various types of workloads. Many such cases are not at all related to the feature sets of regex engines, and probably more related to missed optimization opportunities. (Anyone who has implemented a regex engine knows that the size of the set of missed optimization opportunities is unbounded.) There are of course some of those cases where it comes down to pathological differences. For example, since PCRE uses a backtracking engine even when it isn't necessary (they do have a so-called "DFA" matcher, but it must be invoked explicitly), that means it is susceptible to exponential behavior when Rust's regex engine isn't. But Rust's regex engine has pathological behavior too. The only difference is that Rust's pathological behavior takes the form of large constants, where as PCREs takes the form of exponential growth in the size of the text being searched. > (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. If you're talking about PCRE vs Rust's regex, then I see no reason to claim that one does more or less copying than the other. I suspect both do exactly as little as possible. Certainly, neither of them will copy the search text. > GO just uses PCRE. (Which is weird, isn't RE2 a google project?) No. Go has its own regexp engine: https://golang.org/pkg/regexp/ https://golang.org/pkg/regexp/ The benchmark showcased in the OP for Go uses PCRE, and that's presumably because Go's PCRE variant is faster than Go's native regex engine. See https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... and compare `Go #2` (PCRE) with `Go` (Go implemented regex engine). Go's regex engine in the standard library is written in pure Go, and was written by the same person that wrote RE2. (I wrote Rust's regex engine, but it was heavily inspired by RE2.) Go's regex engine does not have all the same optimizations as RE2, and in particular, it suffers from some very high constant factors in many more cases than what RE2 and Rust's regex engine. While Go's regex engine doesn't exhibit pathological behavior in the form of exponential runtime in the size of the search text, it also can be handily beaten by PCRE in a number of non-pathological cases.
egnehots 9y ago
simplicity source brain load Rust 95% Go 23%
- simias 9y ago
  It's true that performance is not always the main metric to consider but in this case I'm not really sure that Go makes that much of a difference. Take the "regex-redux" benchmark for instance, compare the two versions: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-rust-1.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-go-2.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I don't find the code complexity obviously worse for the Rust version, yet it runs a full order of magnitude faster in this benchmark.
  - weavie 9y ago
    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/faster/go-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-python3.html 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?
    - tex0 9y ago
      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.
      - burntsushi 9y ago
        > 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.
deleted 9y ago
[deleted]
1125 9y ago
They're sorted by highest delta, which makes it look so significant in the first moment. Also, though one of golangs target was to get close to c-like performance, they never intended to be the "performance-killer" since the focus is also strong simplicity and productiveness. More info: https://golang.org/doc/faq#Why_does_Go_perform_badly_on_benchmark_x https://golang.org/doc/faq#Why_does_Go_perform_badly_on_benc...
- timClicks 9y ago
  Another angle where Rust is doing well is in peak RAM usage. Its memory usage is generally (although certainly not universally!) much lower in these examples.
  - 1125 9y ago
    Yeah, no doubt! As already written somewhere above, the GC is not cheap.
cmyr 9y ago
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/faster/go-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- logicallee 9y ago
  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.
  - sagichmal 9y ago
    "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.
    - logicallee 9y ago
      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.
      - sagichmal 9y ago
        It's not intended to be a [Rust-style] systems language [in which one might implement a resource-constrained operating system]. It's absolutely intended to be a [Google-style] systems language [in which one might implement a large distributed data system].
  - yahyaheee 9y ago
Dowwie 9y ago
And that's not all! We really need to see memory consumption.
- rqs 9y ago
  You knew what does the word "mem" on that page means do you :D
  - Dowwie 9y ago
    What mem?
    - codetrotter 9y ago
      In portrait mode on my mobile device that website shows only the amount of time. In landscape it shows more columns of data. That kind of design is quite irritating and not how to do responsive websites right. Perhaps you were looking at the page in portrait mode on a mobile device as well?
      - Dowwie 9y ago
        Thank you for sharing this because I would not have assumed otherwise! Yes, I was looking at it in portrait mode from mobile.
        codetrotter 9y ago
        You are welcome and I am glad I could help. Someone downvoted that comment of mine so for a moment I thought that perhaps it had not been helpful but am glad to hear that it was.
- brohee 9y ago
  Memory usage is hidden on mobile in portrait mode, but displayed in landscape. Od design choice...
Aissen 9y ago
Anyone has tried modifying the go regex benchmark to use https://github.com/BurntSushi/rure-go https://github.com/BurntSushi/rure-go ? It seems to use a library that isn't even on github anymore.
- ysleepy 9y ago
  "Go bindings to Rust's regex engine." - I't would not be in the spirit of the comparison. - Even though most scripting languages also have native regex implementations.
  - burntsushi 9y ago
    The fastest Go benchmark for regex-redux is using PCRE, which is not a native Go regex engine. It's written in C.
    - Aissen 9y ago
      Precisely my point. Most scripting languages also use an engine written in C, too, as grandparent said.
- burntsushi 9y ago
  I had fun with this: [andrew@Cheetah benchgame] time bench-native < /tmp/input5000000.txt ... real 0m20.709s user 1m19.839s sys 0m0.183s [andrew@Cheetah benchgame] time bench-pcre < /tmp/input5000000.txt ... real 0m10.510s user 0m35.362s sys 0m0.211s [andrew@Cheetah benchgame] time bench-rust < /tmp/input5000000.txt ... real 0m2.235s user 0m3.410s sys 0m0.157s For comparison, this is the timing for the Rust program, unchanged from the benchmark site: $ time ./target/release/bench-rust-regex < /tmp/input5000000.txt ... real 0m1.452s user 0m2.643s sys 0m0.158s See https://gist.github.com/BurntSushi/9d35258444fda83de208d31fdd5e9e69 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 in. :-) The PCRE version is definitely sub-optimal. I don't think it's using the JIT, for example. Enabling SIMD optimizations in Rust's regex crate shaves off another 13% (for Rust program) and 9% (for Go program). The SIMD optimizations will be enabled by default in Rust 1.27 for CPUs that support them.
boyter 9y ago
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/ 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++ program will almost always be faster. I wonder how different these benchmarks would be if the Go runtime was set to have GC disabled though. A fairly simple thing to try out and see.
- ashleyn 9y ago
  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.
  - PopsiclePete 9y ago
    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.
ysleepy 9y ago
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.
- jerf 9y ago
  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 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.
dullgiulio 9y ago
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?
- vonseel 9y ago
  > suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. I suspect you are right and some of the posters suffer from “watching the likes roll-in” addiction
- bananarepdev 9y ago
  Probably going to get downvoted for that, but could you recommend me some similar forums? :)
  - dx034 9y ago
    Reddit can be decent IMO (e.g. reddit.com/r/golang)
- chatmasta 9y ago
  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.
  - giancarlostoro 9y ago
    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/ https://rustup.rs/ and go from there, then I can use rustup to update my tooling or add features to the compiled. The other thing is the wealth of packages[0] that expand upon Cargo (Rusts build system and package manager) namely the cargo-deb package which lets me build my Rust projects directly into a Debian package. Continuing on about tooling I have to mention that for IDE's / Text Editors: CLion w/ Rust Plugin is fantastic, but if you want something fully free the VS Code plugin is also amazing for Rust. There's a great effort towards building the Rust Language Server, which thanks to Microsoft is a generic spec that once implemented for one language can be used by any editor / IDE that supports langserver[1]. I will say depending on what you want to do with Rust there can be a bit of a learning curve. I'm still just bleeding my way through some parts because I don't know what everything means in Rust just enough to try different things. I will say Rust is nowhere near where it could be, but it's at a stage where I think it's definitely usable. They definitely took their time to make sure they got things right, and they got plenty right. [0]: https://crates.io/ https://crates.io/ [1]: http://langserver.org/ http://langserver.org/
tw1010 9y ago
Sometimes the most significant aspects of something is unmeasurable.
_Codemonkeyism 9y ago
Why is Java faster than Go?
- cryptos 9y ago
  Why should Go be faster? Both languages use a garbage collector and Java is highly optimized. Plus Java can be optimized even further at runtime.
- glangdale 9y ago
  Because both are very similar languages and Java is way more mature? Go is essentially "Java, from Bell Labs".
- diakritikal 9y ago
  it's not: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- mrweasel 9y ago
  Java, or more specifically the jvm have had some of the worlds smartest developers tweak every corner of the code for 20+ years. Java is faster (in some cases) because it's older and have been tested in pretty much any scenario... And it remains wildly popular, so development never stopped. Similarly Go and Rust are faster than Java in many cases, because the developers have been able to learn for past language like Java, and avoid the same performance pit falls. Or simply because they didn't have to deal with legacy support.
- Thaxll 9y ago
  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/faster/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - benmmurphy 9y ago
    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.
cdoxsey 9y ago
These benchmarks have many flaws. Consider this thread: https://www.reddit.com/r/golang/comments/51mhzv/on_the_binarytrees_benchmark 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/program/binarytrees-rust-2.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... I guess because its not in the stdlib in Go? Course its not in C either, so does C use malloc? Nope. It uses a memory pool too: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Its sad that these benchmarks get used for anything. They tell you next to nothing significant.
- dvfjsdhgfv 9y ago
  > 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.
  - cdoxsey 9y ago
    Yes the maintainer is. People have tried.
    - dvfjsdhgfv 9y ago
      In that case you can set up a separate site with the results. They will be of more value since they'll be more complete.
    - igouy 8y ago
      Which popular third-party Go slab-allocator or arena allocator was used?
  - masklinn 9y ago
    > 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?
skywhopper 9y ago
This would be interesting if there were any comparison of what exactly is slower or faster between the languages or the particular implementations. This data provides a great opportunity, but it's just presented as a dumb contest.
- igouy 8y ago
  >> This data provides a great opportunity, but it's just presented as a dumb contest. Are you going to do-the-work to take that great opportunity?
dvfjsdhgfv 9y ago
The results don't surprise me much, Go isn't that fast. Much more interesting are the results of the Rust vs C++ benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... - it looks like in some cases Rust is actually faster than C++, and that's a big win for me. Also, it would be great to see some Rust vs D benchmarks.
- igouy 8y ago
  >> Also, it would be great to see some Rust vs D benchmarks. Make those measurements and publish them! https://benchmarksgame-team.pages.debian.net/benchmarksgame/play.html#languagex https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
antirez 9y ago
Apples to Oranges, and in the benchmarks involving Apples to Apples, that is C vs Rust, the binary tree test is 2x slower in Rust which is tragic.
- igouy 8y ago
  https://benchmarksgame-team.pages.debian.net/benchmarksgame/dont-jump-to-conclusions.html#apples-and-oranges https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
gekkonier 9y ago
Ah nice, a benchmark.unwrap()!
peteretep 9y ago
In before a specious and infinitely malleable definition of "systems programming language"
Tade0 9y ago
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.
- PSeitz 9y ago
  Garbage collector is actually something you'd want, if it caused no performance hit.
  - atilaneves 9y ago
    Depending on the GC and what the particular definition of "performance" is for your use case (Memory usage? Throughput? Latency? ...), they don't cause a hit. It depends. For instance, if you never hit the GC memory limit in D, it's faster than manually managing memory since you never free it.
  - simias 9y ago
    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.
stunt 9y ago
Don't forget GO is not low level langauge. it is fast because it is compiled. Not sure why there is argument against it. I thought it is obvious for everyone. Rust is lower level, gives less abstractions, and designed for performance. Rust performance is comparable with C and C++. That was the whole idea.
- PyroLagus 9y ago
  I wouldn't say that it gives less abstractions. The Rust devs are obviously careful about adding abstractions that add a performance cost, but Rust has quite a few abstractions that Go doesn't have; generics being the most notable one.
acaloiar 9y ago
Before getting heated about the meaning of these results, remember that benchmarks are good for one thing: measuring performance. Performance is important, but there is laundry list of other factors that programming languages optimize for. Because factors such as development pleasure, mean time to programmer error, and mean time to grok code are not easily quantified and compared, it's difficult to put two languages head-to-head on these often more important factors. These results clearly show how Rust and Go compare on a small set of performance problems. And if you're trying to solve any of these problems using either of these languages, and performance is what you're optimizing for — Rust is a clear winner. I wouldn't try to extrapolate these results to mean anything more than that.
Thaxll 9y ago
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 https://github.com/frol/completely-unscientific-benchmarks
kibwen 9y ago
What's the point of posting this? Rust and Go are only "competitors" in the sense that every language competes with every other. You might as well post the page comparing Go to Fortran or Rust to Clojure. Rust and Go have different objectives, philosophies, tradeoffs, and intended domains. Posts like this seem like they serve no purpose other than to inspire flamewars. And I say this as a heavy Rust user, so don't think that I'm embarrassed by these microbenchmarks. :P
- igouy 8y ago
  >> You might as well post the page comparing… They already have! :-)
thefounder 9y ago
It would be interesting to benchmark the time required to write these programs as well.
borlum 9y ago
Link to live dashboard of Rust vs Go activity on GitHub: https://demo.humio.com/shared/dashboards?token=g79uTaUrFY9kyapyFibN4Ju5VI1LNQxs https://demo.humio.com/shared/dashboards?token=g79uTaUrFY9ky...

144 points by chatmasta 9y ago

whoa

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 much more similar: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... so clearly it's not Rust doing something right, it's the Go implementation doing something wrong. Actually even Java fares (mostly) better: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

oblio 9y ago
The JVM has a ton of work put into it, it wouldn't surprise me if Java is faster than Go for quite a few things.
jon-wood 9y ago
It’s less Go doing something wrong and more just that they do different things. Go has a garbage collector which will naturally slow things down somewhat, while Rust handles memory (de)allocation at compile time.
- _ph_ 9y ago
  The problem is, that some of this benchmarks rules prevent the Go solution from using the same efficient code than its competitors, so the numbers are just not valid.
- hellofunk 9y ago
  > Rust handles memory (de)allocation at compile time You are saying that Rust is doing its runtime memory allocation at compile time? Are you sure you don’t mean compile time management of memory? Two very different different things.
  - notheguyouthink 9y ago
    Isn't one of those impossible? Ie, there's only one reasonable interpretation of that sentence? Not saying being explicit isn't important, just trying to understand you.
    - hellofunk 9y ago
      Yes, what poster commented is in fact impossible.
- atilaneves 9y ago
  I'm still puzzled by the continued belief that a tracing GC will "naturally slow things down somewhat". Why do you think that's the case?
  - yoklov 9y ago
    You’re forcing the program to rediscover facts about itself at runtime. This is not free. That doesn’t mean a GCed lang is always slower than a lang where memory is managed manually. It means that the theoretically optimal implementation using GC has to do more work than the theoretically optimal implementation that manages its own memory. In the case where the theoretically optimal implementation needs a GC, the unmanaged language could always implement that anyway, but that’s vanishingly rare — typically a GC gets its speedup by using pools, which are also available to unmanaged code.
slezyr 9y ago
> Rust vs. C++ benchmark the results are much more similar Not really... Try compare sources of those programs. For example spectral-norm uses OpenMP and other things that make source look really different from the one you would write in real life. Rust program looks much simpler and closer to real life code. https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-rust-4.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-gpp-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- codetrotter 9y ago
  > > the results are much more similar Parent is talking about performance, not source code
  - slezyr 9y ago
    True, but that performance gained by writing code in a way which most devs wouldn't do.
    - igouy 8y ago
      I very much doubt that you actually know what most devs would do.
v_lisivka 9y ago
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.
- p0nce 9y ago
  If you use a LLVM compiler, _mm_cvtpd_ps just translate to LLVM IR and is not Intel specific anymore.
  - giancarlostoro 9y ago
    They're using g++ though, afaik that's just using GCC is it not? But good catch altogether.
- Const-me 9y ago
  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.
  - steveklabnik 9y ago
    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.html 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_ps.html https://doc.rust-lang.org/beta/core/arch/x86_64/fn._mm_cvtpd...
Tuna-Fish 9y ago
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-trees The benchmark needs to build a massive binary tree. The Rust implementation allocates it's tree in a TypedArena, which is basically a bump allocator for objects that are all dropped simultaneously. It requires very minimal metadata or work per allocation. (Not zero, because it does properly call all destructors.) The GO implementation has to use the platform allocator. The results shouldn't be very surprising... 3. Manderbrot Not sure, but I think the Rust version is designed for autovectorization while the Go one is scalar. After that the Go runtimes are within 2.5x of the Rust ones.
- Jweb_Guru 9y ago
  > Not zero, because it does properly call all destructors. I believe that there is an optimization that allows this to be completely avoided for types with only trivial or no destructors.
- pron 9y ago
  > The GO implementation has to use the platform allocator. So does the Java implementation, and still it fares much (3x) better than Go.
  - deleted 9y ago
    [deleted]
  - pcwalton 9y ago
    Because the Java GC has better throughput than the Go GC. The Go GC makes enormous throughput sacrifices by prioritizing latency above all else.
- burntsushi 9y ago
  With respect to your comments about regex, could you please share with me where you got your information? I would love to know so that I can go bug whoever it is to correct it. > Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it. The only true part of this is that Rust's regex engine lacks many features found in PCRE. Mostly, these features revolve around things that are either impossible or not-known/difficult to add to a linear time implementation in an efficient way. The most popular features among these are backreferences and various types of lookaround. However, it is completely unsubstantiated to say that Rust's regex engine is faster than PCRE. At best, you can say that they are competitive with each other, where one regex engine will do better than the other on various types of workloads. Many such cases are not at all related to the feature sets of regex engines, and probably more related to missed optimization opportunities. (Anyone who has implemented a regex engine knows that the size of the set of missed optimization opportunities is unbounded.) There are of course some of those cases where it comes down to pathological differences. For example, since PCRE uses a backtracking engine even when it isn't necessary (they do have a so-called "DFA" matcher, but it must be invoked explicitly), that means it is susceptible to exponential behavior when Rust's regex engine isn't. But Rust's regex engine has pathological behavior too. The only difference is that Rust's pathological behavior takes the form of large constants, where as PCREs takes the form of exponential growth in the size of the text being searched. > (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. If you're talking about PCRE vs Rust's regex, then I see no reason to claim that one does more or less copying than the other. I suspect both do exactly as little as possible. Certainly, neither of them will copy the search text. > GO just uses PCRE. (Which is weird, isn't RE2 a google project?) No. Go has its own regexp engine: https://golang.org/pkg/regexp/ https://golang.org/pkg/regexp/ The benchmark showcased in the OP for Go uses PCRE, and that's presumably because Go's PCRE variant is faster than Go's native regex engine. See https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... and compare `Go #2` (PCRE) with `Go` (Go implemented regex engine). Go's regex engine in the standard library is written in pure Go, and was written by the same person that wrote RE2. (I wrote Rust's regex engine, but it was heavily inspired by RE2.) Go's regex engine does not have all the same optimizations as RE2, and in particular, it suffers from some very high constant factors in many more cases than what RE2 and Rust's regex engine. While Go's regex engine doesn't exhibit pathological behavior in the form of exponential runtime in the size of the search text, it also can be handily beaten by PCRE in a number of non-pathological cases.

egnehots 9y ago

simplicity source brain load Rust 95% Go 23%

simias 9y ago
It's true that performance is not always the main metric to consider but in this case I'm not really sure that Go makes that much of a difference. Take the "regex-redux" benchmark for instance, compare the two versions: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-rust-1.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-go-2.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I don't find the code complexity obviously worse for the Rust version, yet it runs a full order of magnitude faster in this benchmark.
- weavie 9y ago
  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/faster/go-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-python3.html 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?
  - tex0 9y ago
    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.
    - burntsushi 9y ago
      > 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.

deleted 9y ago

[deleted]

1125 9y ago

They're sorted by highest delta, which makes it look so significant in the first moment. Also, though one of golangs target was to get close to c-like performance, they never intended to be the "performance-killer" since the focus is also strong simplicity and productiveness. More info: https://golang.org/doc/faq#Why_does_Go_perform_badly_on_benchmark_x https://golang.org/doc/faq#Why_does_Go_perform_badly_on_benc...

timClicks 9y ago
Another angle where Rust is doing well is in peak RAM usage. Its memory usage is generally (although certainly not universally!) much lower in these examples.
- 1125 9y ago
  Yeah, no doubt! As already written somewhere above, the GC is not cheap.

cmyr 9y ago

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/faster/go-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

logicallee 9y ago
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.
- sagichmal 9y ago
  "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.
  - logicallee 9y ago
    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.
    - sagichmal 9y ago
      It's not intended to be a [Rust-style] systems language [in which one might implement a resource-constrained operating system]. It's absolutely intended to be a [Google-style] systems language [in which one might implement a large distributed data system].
- yahyaheee 9y ago

Dowwie 9y ago

And that's not all! We really need to see memory consumption.

rqs 9y ago
You knew what does the word "mem" on that page means do you :D
- Dowwie 9y ago
  What mem?
  - codetrotter 9y ago
    In portrait mode on my mobile device that website shows only the amount of time. In landscape it shows more columns of data. That kind of design is quite irritating and not how to do responsive websites right. Perhaps you were looking at the page in portrait mode on a mobile device as well?
    - Dowwie 9y ago
      Thank you for sharing this because I would not have assumed otherwise! Yes, I was looking at it in portrait mode from mobile.
      - codetrotter 9y ago
        You are welcome and I am glad I could help. Someone downvoted that comment of mine so for a moment I thought that perhaps it had not been helpful but am glad to hear that it was.
brohee 9y ago
Memory usage is hidden on mobile in portrait mode, but displayed in landscape. Od design choice...

Aissen 9y ago

Anyone has tried modifying the go regex benchmark to use https://github.com/BurntSushi/rure-go https://github.com/BurntSushi/rure-go ? It seems to use a library that isn't even on github anymore.

ysleepy 9y ago
"Go bindings to Rust's regex engine." - I't would not be in the spirit of the comparison. - Even though most scripting languages also have native regex implementations.
- burntsushi 9y ago
  The fastest Go benchmark for regex-redux is using PCRE, which is not a native Go regex engine. It's written in C.
  - Aissen 9y ago
    Precisely my point. Most scripting languages also use an engine written in C, too, as grandparent said.
burntsushi 9y ago
I had fun with this: [andrew@Cheetah benchgame] time bench-native < /tmp/input5000000.txt ... real 0m20.709s user 1m19.839s sys 0m0.183s [andrew@Cheetah benchgame] time bench-pcre < /tmp/input5000000.txt ... real 0m10.510s user 0m35.362s sys 0m0.211s [andrew@Cheetah benchgame] time bench-rust < /tmp/input5000000.txt ... real 0m2.235s user 0m3.410s sys 0m0.157s For comparison, this is the timing for the Rust program, unchanged from the benchmark site: $ time ./target/release/bench-rust-regex < /tmp/input5000000.txt ... real 0m1.452s user 0m2.643s sys 0m0.158s See https://gist.github.com/BurntSushi/9d35258444fda83de208d31fdd5e9e69 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 in. :-) The PCRE version is definitely sub-optimal. I don't think it's using the JIT, for example. Enabling SIMD optimizations in Rust's regex crate shaves off another 13% (for Rust program) and 9% (for Go program). The SIMD optimizations will be enabled by default in Rust 1.27 for CPUs that support them.

boyter 9y ago

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/ 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++ program will almost always be faster. I wonder how different these benchmarks would be if the Go runtime was set to have GC disabled though. A fairly simple thing to try out and see.

ashleyn 9y ago
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.
- PopsiclePete 9y ago
  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.

ysleepy 9y ago

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.

jerf 9y ago
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 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.

dullgiulio 9y ago

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?

vonseel 9y ago
> suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. I suspect you are right and some of the posters suffer from “watching the likes roll-in” addiction
bananarepdev 9y ago
Probably going to get downvoted for that, but could you recommend me some similar forums? :)
- dx034 9y ago
  Reddit can be decent IMO (e.g. reddit.com/r/golang)
chatmasta 9y ago
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.
- giancarlostoro 9y ago
  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/ https://rustup.rs/ and go from there, then I can use rustup to update my tooling or add features to the compiled. The other thing is the wealth of packages[0] that expand upon Cargo (Rusts build system and package manager) namely the cargo-deb package which lets me build my Rust projects directly into a Debian package. Continuing on about tooling I have to mention that for IDE's / Text Editors: CLion w/ Rust Plugin is fantastic, but if you want something fully free the VS Code plugin is also amazing for Rust. There's a great effort towards building the Rust Language Server, which thanks to Microsoft is a generic spec that once implemented for one language can be used by any editor / IDE that supports langserver[1]. I will say depending on what you want to do with Rust there can be a bit of a learning curve. I'm still just bleeding my way through some parts because I don't know what everything means in Rust just enough to try different things. I will say Rust is nowhere near where it could be, but it's at a stage where I think it's definitely usable. They definitely took their time to make sure they got things right, and they got plenty right. [0]: https://crates.io/ https://crates.io/ [1]: http://langserver.org/ http://langserver.org/

tw1010 9y ago

Sometimes the most significant aspects of something is unmeasurable.

_Codemonkeyism 9y ago

Why is Java faster than Go?

cryptos 9y ago
Why should Go be faster? Both languages use a garbage collector and Java is highly optimized. Plus Java can be optimized even further at runtime.
glangdale 9y ago
Because both are very similar languages and Java is way more mature? Go is essentially "Java, from Bell Labs".
diakritikal 9y ago
it's not: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
mrweasel 9y ago
Java, or more specifically the jvm have had some of the worlds smartest developers tweak every corner of the code for 20+ years. Java is faster (in some cases) because it's older and have been tested in pretty much any scenario... And it remains wildly popular, so development never stopped. Similarly Go and Rust are faster than Java in many cases, because the developers have been able to learn for past language like Java, and avoid the same performance pit falls. Or simply because they didn't have to deal with legacy support.
Thaxll 9y ago
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/faster/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- benmmurphy 9y ago
  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.

cdoxsey 9y ago

These benchmarks have many flaws. Consider this thread: https://www.reddit.com/r/golang/comments/51mhzv/on_the_binarytrees_benchmark 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/program/binarytrees-rust-2.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... I guess because its not in the stdlib in Go? Course its not in C either, so does C use malloc? Nope. It uses a memory pool too: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Its sad that these benchmarks get used for anything. They tell you next to nothing significant.

dvfjsdhgfv 9y ago
> 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.
- cdoxsey 9y ago
  Yes the maintainer is. People have tried.
  - dvfjsdhgfv 9y ago
    In that case you can set up a separate site with the results. They will be of more value since they'll be more complete.
  - igouy 8y ago
    Which popular third-party Go slab-allocator or arena allocator was used?
- masklinn 9y ago
  > 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?

skywhopper 9y ago

This would be interesting if there were any comparison of what exactly is slower or faster between the languages or the particular implementations. This data provides a great opportunity, but it's just presented as a dumb contest.

igouy 8y ago
>> This data provides a great opportunity, but it's just presented as a dumb contest. Are you going to do-the-work to take that great opportunity?

dvfjsdhgfv 9y ago

The results don't surprise me much, Go isn't that fast. Much more interesting are the results of the Rust vs C++ benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... - it looks like in some cases Rust is actually faster than C++, and that's a big win for me. Also, it would be great to see some Rust vs D benchmarks.

igouy 8y ago
>> Also, it would be great to see some Rust vs D benchmarks. Make those measurements and publish them! https://benchmarksgame-team.pages.debian.net/benchmarksgame/play.html#languagex https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

antirez 9y ago

Apples to Oranges, and in the benchmarks involving Apples to Apples, that is C vs Rust, the binary tree test is 2x slower in Rust which is tragic.

igouy 8y ago
https://benchmarksgame-team.pages.debian.net/benchmarksgame/dont-jump-to-conclusions.html#apples-and-oranges https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

gekkonier 9y ago

Ah nice, a benchmark.unwrap()!

peteretep 9y ago

In before a specious and infinitely malleable definition of "systems programming language"

Tade0 9y ago

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.

PSeitz 9y ago
Garbage collector is actually something you'd want, if it caused no performance hit.
- atilaneves 9y ago
  Depending on the GC and what the particular definition of "performance" is for your use case (Memory usage? Throughput? Latency? ...), they don't cause a hit. It depends. For instance, if you never hit the GC memory limit in D, it's faster than manually managing memory since you never free it.
- simias 9y ago
  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.

stunt 9y ago

Don't forget GO is not low level langauge. it is fast because it is compiled. Not sure why there is argument against it. I thought it is obvious for everyone. Rust is lower level, gives less abstractions, and designed for performance. Rust performance is comparable with C and C++. That was the whole idea.

PyroLagus 9y ago
I wouldn't say that it gives less abstractions. The Rust devs are obviously careful about adding abstractions that add a performance cost, but Rust has quite a few abstractions that Go doesn't have; generics being the most notable one.

acaloiar 9y ago

Before getting heated about the meaning of these results, remember that benchmarks are good for one thing: measuring performance. Performance is important, but there is laundry list of other factors that programming languages optimize for. Because factors such as development pleasure, mean time to programmer error, and mean time to grok code are not easily quantified and compared, it's difficult to put two languages head-to-head on these often more important factors. These results clearly show how Rust and Go compare on a small set of performance problems. And if you're trying to solve any of these problems using either of these languages, and performance is what you're optimizing for — Rust is a clear winner. I wouldn't try to extrapolate these results to mean anything more than that.

Thaxll 9y ago

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 https://github.com/frol/completely-unscientific-benchmarks

kibwen 9y ago

What's the point of posting this? Rust and Go are only "competitors" in the sense that every language competes with every other. You might as well post the page comparing Go to Fortran or Rust to Clojure. Rust and Go have different objectives, philosophies, tradeoffs, and intended domains. Posts like this seem like they serve no purpose other than to inspire flamewars. And I say this as a heavy Rust user, so don't think that I'm embarrassed by these microbenchmarks. :P

igouy 8y ago
>> You might as well post the page comparing… They already have! :-)

thefounder 9y ago

It would be interesting to benchmark the time required to write these programs as well.

borlum 9y ago

Link to live dashboard of Rust vs Go activity on GitHub: https://demo.humio.com/shared/dashboards?token=g79uTaUrFY9kyapyFibN4Ju5VI1LNQxs https://demo.humio.com/shared/dashboards?token=g79uTaUrFY9ky...