
Rust programs versus Go - chatmasta
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-go.html
======
cdoxsey
These benchmarks have many flaws.

Consider this thread:
[https://www.reddit.com/r/golang/comments/51mhzv/on_the_binar...](https://www.reddit.com/r/golang/comments/51mhzv/on_the_binarytrees_benchmark)

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/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/program/binarytrees-rust-2.html).

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/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-3.html)

Its sad that these benchmarks get used for anything. They tell you next to
nothing significant.

~~~
glangdale
There are many predictable things in life: the tendency of up-and-comer
languages to blitz these benchmarks due to careful optimization, and the
tendency of people whose pet language has lost on a benchmark or two to get on
here and write off the idea that anyone should ever benchmark cross-language.

Some of the benchmarks are pretty ridiculous and flawed. Others look pretty
straightforwardly comparable. I have trouble looking at n-body (just
fr'instance) and seeing any major difference or cheat on the Rust side (or for
that matter, the much more mature C/C++ sides). Leaving aside the obviously
ridiculous (the regex one is a absolute festival of 'who brought a fast regex
library to the gunfight'), the trend is pretty clear: Go's code generator is
pretty ordinary (it's not actually aimed at achieving ultimate code quality at
any compile-time cost, so it's working as designed) and GC isn't free.

~~~
cdoxsey
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
of thumb like "Go is 2x slower than C" or "Python is 10x slower than C" which
is complete nonsense. It really matters what the code is doing.

In particular for server programs developers come to these conclusions without
considering the multi-core environment they're working in. ie, redis is a
really fast key-value store that will use 1 core on a 32 core machine.

And as it turns out all the tips and tricks to improving performance in these
cases works in all the other languages too. So just what are we to conclude
from them?

I suppose a nice simple math benchmark can demonstrate that LLVM or GCC is
better at optimizing code than Go?

~~~
naasking
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.

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

~~~
naasking
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.

~~~
vanderZwan
I know what Kolmogorov complexity is, I was trying to get at something else:
removing boilerplate is one thing, but the other extreme isn't all that
helpful either. When discussing information theory, one should always remember
that _white noise has the maximum amount of information_ , so the theoretical
best scoring programming language of your measurement would be
indistinguishable from white noise. Hardly productive, right? One of the key
things about higher programming languages is that they add structure and
patterns - in information theory terms: redundancy - to make it easier for
programmers to follow what is going on.

I mentioned APL because programs in it usually consist of a handful of symbols
with very little repetition. The symbols/performance ratio is really good for
APL. Or to be even more on the nose: think of code golfing languages[0].

[0]
[https://en.wikipedia.org/wiki/Code_golf#Dedicated_golfing_la...](https://en.wikipedia.org/wiki/Code_golf#Dedicated_golfing_languages)

~~~
naasking
> so the theoretical best scoring programming language of your measurement
> would be indistinguishable from white noise.

The compressed program is necessarily shorter than the output it's trying to
reproduce, unless the output is itself pure noise. Therefore noise and
programs must be distinguishable.

> One of the key things about higher programming languages is that they add
> structure and patterns - in information theory terms: redundancy - to make
> it easier for programmers to follow what is going on.

Structures and abstractions don't introduce redundancy, they are actually
_compression_. A while loop is clearly more compressed than an infinite
sequence of if-statements repeatedly testing the termination condition. An
abstraction, like a list or monad, eliminates significant boilerplate that
would be needed to reproduce the output of the list or monad.

Adding redundancy makes things harder to follow because you need to keep more
state in your head. Adding the right kind of compression makes things easier
for humans to follow (obviously there are bad kinds of compression, like alpha
conversion to random strings).

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

~~~
chatmasta
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.

~~~
notheguyouthink
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 more nice to write in when you're.. well, writing it out.
I guess I tend to write as I think about data structures, abstractions,
general design. I don't draw it ahead of time or w/e, I just write code. Go is
very minimal, and is pretty forgiving to quick rewrites/etc. In Rust I found
myself writing myself into a corner constantly when all I was trying to do was
get an idea out of my head.

With that said, I vastly preferred Rust's feeling of knowing _exactly_ what my
program is doing. No question on if something is nil or not, you know it is or
isn't _(or know it 's unknown haha)_.

I think for me, in another 2 years I'll push again for Rust > Go in my shop as
I imagine the Rust tooling will have improved to the point where it's easier
and more quick to write things. Rust was experiencing a lot of cargo package
churn, I spent hours debugging which packages worked together, it was a
headache. Even understanding errors was a bit of a headache, despite the
compiler trying really hard. Rust is making great strides though, and even
though I use Go to get shit done, Rust is probably my favorite language.. that
I don't use heh.

 _edit_ : Oh yea, and green threads, god do I wish Rust had green threads. I
found Rust to be similar to Go in multithreading ergonomics, but I couldn't
use them in the same manner as with Go - ie, fire off as many as I want. There
are several libraries in development that should take care of this though, I
believe.

~~~
vanderZwan
> 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?

~~~
notheguyouthink
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.

~~~
vanderZwan
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!

~~~
vertex-four
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.

~~~
steveklabnik
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.

------
simias
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/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/rust-gpp.html) 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/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/rust-java.html)

~~~
Tuna-Fish
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.

~~~
pron
> The GO implementation has to use the platform allocator.

So does the Java implementation, and still it fares much (3x) better than Go.

~~~
pcwalton
Because the Java GC has better throughput than the Go GC. The Go GC makes
enormous throughput sacrifices by prioritizing latency above all else.

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

~~~
logicallee
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
"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
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
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].

------
1125
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_benc...](https://golang.org/doc/faq#Why_does_Go_perform_badly_on_benchmark_x)

~~~
timClicks
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
Yeah, no doubt! As already written somewhere above, the GC is not cheap.

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

------
egnehots

      simplicity
    
      source      brain load
      Rust        95%
      Go          23%

~~~
simias
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/...](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)

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
Go seems to perform really poorly in the regex-redux. Against both Node and
Python Go is way faster (as one would expect) apart from with the regex-
redux..

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/go-node.html)
[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/go-python3.html)

Does Go just suck with it's regex performance? Would this be easy to fix by
just pulling in a C regex library?

~~~
jerf
I disagree with the people saying the benchmarks game is useless. It mostly
seems to conform to my own experiences with the various languages involved.

The exception is the regex benchmark, which has little to do with the
languages and everything to do with the regex library used by the language. If
the dynamic scripting languages were required to use regex engines implemented
in pure Python/Perl/PHP/JS, their performance in the game would collapse on
the regex benchmark.

Go's standard library provides a regex library that provides certain O()
guarantees, but has a significantly larger constant factor than PCRE-like
regexs. Benchmarks tend to hit cases where PRCE is faster, but it's not hard
to construct a benchmark where the Go standard library will be arbitrarily
faster than some of the other languages, because that's a characteristic of
big-O differences.

(In general, one should always be careful of claims that some block of code is
X times faster or slower than another; the comparison only has meaning if
they're in the same big-O class, or at least de facto in the same big-O class,
e.g., O(n logn) and O(n logn logn) are basically the same class in practice.
It's also important to make sure the problem being benchmarked is large enough
to get past the constant factors that may be involved. I'm not saying those
aren't important, but _if_ you want an "X-times faster" sort of comparison you
need to shrink the constant factors into irrelevance first. I've seen cases
where people blithely claim some bit of code is 100,000 faster than some
other, but really, it's a big-O difference.)

~~~
edapa
> Go's standard library provides a regex library that provides certain O()
> guarantees, but has a significantly larger constant factor than PCRE-like
> regexs.

While that is true, Rust's regex library makes the same guarantees.

I'd also like to push back on the idea that perf comparisons are meaningless
if one implementation has degenerate cases. Pathological behavior in a
backtracking engine happens very rarely, and backtrackers typically come with
features that are not supplied by O(n) engines. Someone in the PCRE camp might
complain that the benchmark isn't fair because go's engine can't handle
backreferences. The different approaches come with different features
(backreferences vs garenteed O(n) running time), but they do have a place
where their problem domains overlap. It is not useless to examine how they
perform in that area.

~~~
jerf
"I'd also like to push back on the idea that perf comparisons are meaningless
if one implementation has degenerate cases."

That's not what I said. I said, you can't use "X times faster" comparisons if
the O() of the two algorithms in question are not more-or-less the same. That
does not prevent you from still characterizing performance differences. You
just can't do it via "X times faster" statements, because those are only well-
defined for things separated by linear factors, and practically defined for
things separated by practically linear factors. f(x) = x^2 is not "2 times
bigger" than g(x) = x, or any number of "times bigger", whereas h(x) = 3x + 5
can be reasonably said to be "3 times bigger" than i(x) = x + 50, even though
it is not the case that h(x) = 3i(x).

------
kibwen
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
>> You might as well post the page comparing…

They already have! :-)

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

------
dvfjsdhgfv
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/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/rust-gpp.html) \- 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
>> 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/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/play.html#languagex)

------
Tade0
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
Garbage collector is actually something you'd want, if it caused no
performance hit.

~~~
simias
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.

~~~
PopsiclePete
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.

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

Guess again.

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

Given that one of Rust's main shticks is concurrency and parallelism it's an
odd thing to say. You can always use an Arc<> if you want reference counting
between threads which is sort-of GC but opt-in and perfectly deterministic.

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

------
antirez
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
[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/dont-jump-to-conclusions.html#apples-and-
oranges)

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

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

------
borlum
Link to live dashboard of Rust vs Go activity on GitHub:

[https://demo.humio.com/shared/dashboards?token=g79uTaUrFY9ky...](https://demo.humio.com/shared/dashboards?token=g79uTaUrFY9kyapyFibN4Ju5VI1LNQxs)

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

------
tw1010
Sometimes the most significant aspects of something is unmeasurable.

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

------
gekkonier
Ah nice, a benchmark.unwrap()!

------
_Codemonkeyism
Why is Java faster than Go?

~~~
Thaxll
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/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/go.html)

~~~
benmmurphy
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.

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

~~~
burntsushi
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/9d35258444fda83de208d31fd...](https://gist.github.com/BurntSushi/9d35258444fda83de208d31fdd5e9e69)
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.

~~~
Aissen
Awesome work, thanks !

~~~
Aissen
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 < ../input500000.txt > /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.

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

~~~
rqs
You knew what does the word "mem" on that page means do you :D

~~~
Dowwie
What mem?

~~~
codetrotter
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
Thank you for sharing this because I would not have assumed otherwise! Yes, I
was looking at it in portrait mode from mobile.

~~~
codetrotter
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.

------
CodinM
whoa

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

