
Rust Faster - jaxondu
https://llogiq.github.io/2015/10/03/fast.html
======
geofft
Fascinating things I learned from this article:

1\. The benchmarks game is mostly a game of who can solve the problem fastest
with the constraint of "all the code has to be in this language." It's not
about how anyone would realistically write the code; if ludicrous
optimizations were in-scope for any real-world project, so would be _calling
out to a different language_. It's worse than the usual problem of benchmarks
being unrepresentative of real code; the implementations are also
unrepresentative.

2\. Apparently performant Haskell involves unchecked raw memory access? What's
the story there?

~~~
qznc
> the constraint of "all the code has to be in this language."

No that is not a usual constraint, many implementations use third party
libraries. E.g., regexdna implementations usually rely on some regex library
and pidigits just measures libgmp.

~~~
mcguire
It is a valid constraint, though. Many long-standing complaints from the Java
side of things were along the lines of "We can't use libgmp."

~~~
igouy
[http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...](http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=java&id=2#sourcecode)

------
Everlag
I've been working with rust for about a week now and I've found it a mirror of
go in several ways.

Go aims to be simple with the aim of being 'easy' to start writing
idiomatically within a few days of jumping into the language. Comparatively,
rust is a behemoth in terms of complexity.

There's the completely relevant compilation speed difference: if rust could
compile within 5-10x the time go does, it would be much more pleasant to work
with. Being able to compile within 2 seconds on large projects is crazy for
iteration speed; having to wait upwards of 10 seconds on toy projects is not.

However, rust is stupid fast while also being safer than go. Also, generics;
that's a flamewar for another day.

Context: I've been working with go for around 2-3 years now. I recently
decided to pick up rust because of the guarantees it provides along with the
crazy performance.

~~~
kibwen
You'll be happy to hear that compilation speed is the foremost priority of the
Rust developers at the moment, and is the result of a technical-debt-laden
codebase (having survived four years of traumatic language evolution) rather
than any intrinsic property of the language. :) Huge improvements are in the
pipe.

~~~
IshKebab
Do you have any evidence that it _isn 't_ an intrinsic property of the
language? I would have thought all that type inference is non-trivial to
calculate.

~~~
Manishearth
The slowest part is the LLVM passes. typecheck isn't very fast either, but it
can be parallelized and it's much faster than the LLVM part.

We don't really do any optimizations on the Rust side and just hand over IR to
LLVM. This IR isn't of the type LLVM was built to deal with (pervasive
noalias, lots of iterators, etc). It can optimize it, just that it's slow. We
can work on giving better IR there.

So type check is slow, but it isn't the _reason_ we're slow. (Still,
improvements to type check will help)

------
acconsta
The author also points out that some of the benchmarks poorly represent real
workloads:

"Bottom up (since the worst offenders are now first),

binary-trees is silly since it measures allocation speed for a case that
simply doesn't exist in real code;

thread-ring is basically insane, since nobody ever bottlenecks like that;

chameneos-redux's C++ implementation is ridiculous. The C is not so
ridiculous, but you still have the problem that basically every language in
the top few spots does something completely different;

pidigits tests whether you have bindings to GMP;

regex-dna tests a regex engine on a small subset of cases (arguably the first
half-acceptable benchmark);

k-nucleotide tests who has the best hash table for this particular silly
scheme, and they don't all even do the same thing (eg. Scala precompacts, like
my new Rust version);

mandelbrot is kind'a OK;

reverse-complement would be kind'a OK if not for a few hacky implementations
(like the Rust);

spectral-norm is kind'a OK;

Haskell basically cheats fasta (which is why I copied it);

meteor-contest is too short to mean anything at all;

fannkuch-redux is probably kind'a OK,

n-body is kind'a OK.

So maybe 5/13 are acceptable, and I'd still only use 4 of those. I think if
looking at mandelbrot, spectral-norm, fannkuch-redux and n-body you can argue
the benches are a reasonable measure of peak performance. However, these cases
are also all too small and simple to really be convincing either, nor is it
particularly fair (where's NumPy for Python?)."

[https://users.rust-lang.org/t/blog-rust-
faster/3117/12?u=acc...](https://users.rust-lang.org/t/blog-rust-
faster/3117/12?u=acconsta)

~~~
igouy
>>bad at simulating real workloads<<

Have you looked at the benchmarks game website?

Please show where the benchmarks game website claims that those tasks simulate
"real workloads" (whatever that means).

 _You will see_ "Your application is the ultimate benchmark" and "These are
just 10 tiny examples" and …

[http://benchmarksgame.alioth.debian.org/dont-jump-to-
conclus...](http://benchmarksgame.alioth.debian.org/dont-jump-to-
conclusions.html)

~~~
acconsta
I apologize if I gave the impression I was claiming otherwise. It's just
context for the discussion.

~~~
igouy
Veedrac "points out" his _likes and dislikes_ , that doesn't mean his _likes
and dislikes_ are "The Truth".

When Veedrac dismissively tells you - "pidigits tests whether you have
bindings to GMP" \- you should ask why he hasn't told you that the
measurements can be different even when all the programs use GMP; you should
ask why he hasn't told you that the measurements also show the difference for
the same language implementation when programs do and don't use GMP.

 _etc etc_

------
techdragon
Every time I look at rust and posts about rust like this one. It occurs to me
that "I can use this to write 'C' libraries" and a variable number of moments
later, I think to myself that I'll keep Go at the bottom of my list of
languages to learn to program in, after Ruby, Lisp, Fortran, COBOL, and
Intercal, I'll get to Go one day, if it's still relevant to me, for now Rust +
Erlang / Elixir on FreeBSD is like having my own personal unicorn.

I've been meaning to work on a proper "Erlang/OTP-ish" framework for Python
for a long time, Pulsar[1] is a good start but needs more developers, and more
documentation in order to grow. It has an example that does web sockets with
normal Django, no massive hacks. (Which someone more familiar with Django
should really check out and talk about more widely) But no Flask example?

1 - [https://github.com/quantmind/pulsar](https://github.com/quantmind/pulsar)

~~~
mcguire
" _a proper "Erlang/OTP-ish" framework_"

Rust's original M:N threading almost begged for an OTP-style approach (as in,
it looked like Erlang with a non-Prolog syntax :-)). But I think the current
threading interfaces are pretty welcoming for an OTP style. Anyone working on
that?

------
fijal
"A staple of all performance discussion is the great Computer Language
Benchmarks Game." this is so sad, but true

------
dikaiosune
Very cool, and definitely gives me some insight into those benchmarks. Which
makes me wonder -- are there benchmarks for "boring" programs in a variety of
languages? I'm generally more interested in the execution speed of
implementations that I would actually have time to write when on a deadline.

~~~
kibwen
The best thing for your purposes would be a site that attempted to optimize
for the appearance of idiomatic code, which you could then secretly use to
gauge the performance of code that's idiomatic to each language. In other
words, entirely remove performance showboating as an incentive. Rosetta Code
([http://rosettacode.org/wiki/Rosetta_Code](http://rosettacode.org/wiki/Rosetta_Code))
may be the closest to what you want, though I can guess that most of the Rust
implementations were written prior to 1.0 and won't even compile anymore, let
alone represent idiomatic code. :P

~~~
dikaiosune
I like that idea -- although I would agree that Rosetta Code often does not
represent idiomatic code, even for longer-established languages. The wikibooks
algorithms book might also be a good candidate, although I've not yet seen
Rust on there.

------
mcguire
" _k_nucleotide is a test of how fast your Hash map is._ "

Speaking of Rusts' HashMap, the Robin Hood map is pretty darn sweet (and I say
that as someone who translated a Pythonish map to Rust), but the last time I
looked it was still throttled by SipHash.[1] Is there any progress on SIMD-ing
that?

[1] "Safety vs. performance", etc., etc.

~~~
pcwalton
SipHash as implemented in Rust is actually pretty fast for long keys; it's
only for short keys that it falls down (and SIMDification won't help too much
on short keys).

~~~
mcguire
What's a "long key" in this case? I've only looked at it for modest-length
strings.

------
imaginenore
The requirement to read line by line is ridiculous.

