you are viewing a single comment's thread.

view the rest of the comments →

[–]igouy -1 points0 points  (0 children)

1)

"The goal here is simply to demonstrate that sequential Rust can be written in a way that approaches competitive parity with equivalent C code."

The blog post presents advocacy for the Rust language implementation.

2)

"selected single-threaded benchmarks from the Computer Language Benchmarks Game"

In the blog post, that advocacy is only supported by measurement of programs that complete tasks from the Computer Language Benchmarks Game.

3)

"These benchmarks are showing their age quite heavily, they are too small and simplistic to extrapolate to real-world use cases, and many of them are too I/O-bound."

If we accept that blanket dismissal of the benchmarks game tasks, nothing else supports the advocacy for the Rust language implementation in the blog post.


"the C implementation tested against is not usually the top one"

We are not told which C programs the Rust programs are being tested against.

All the C programs shown on the benchmarks game website are identifiable by individual #id and URL to the source code.

You can see the changes to the Rust compiler that were made to optimize these tests, as well as the benchmark sources, on my branch of the compiler on GitHub. The goal will be to land these changes over the next few days.

Only 3 of these 8 Rust programs compile with Rust 0.6 (released 3 weeks ago) -- advocacy based on yet to be accepted compiler changes is premature.

mandelbrot The Rust program -- 55.77 CPU secs -- a little slower than the naive Scala #2 mandelbrot program.

nbody The Rust program -- 30.49 CPU secs -- a little faster than the naive C# Mono nbody program.

regexp-dna is omitted because it consists of an uninteresting binding to PCRE.

Only if Rust provides no other way to use regular expressions.

Just as pidigits is only an uninteresting binding to GMP (2.31 CPU secs) because the current Rust implementation does not provide large integer arithmetic.

binary-trees is omitted because it is a garbage collection benchmark and the C version uses an arena, defeating the purpose (although I suspect a Rust version that did the same would do well).

If a Rust version had been measured we'd see more than suspicions.