[mbrubeck]

In other Rust/benchmarksgame news, I just submitted a simple fix to the Rust program for "reverse-complement" that makes it faster than the fastest C++ program, on my computer. The old version was spending 2/3 of its time just reading the input into memory, because it wasn't allocating a large enough buffer up front.

https://github.com/TeXitoi/benchmarksgame-rs/pull/44

I'm also working on some additional changes that make it even faster than the C version (again, on my computer) by improving how it divides work across CPUs:

https://github.com/TeXitoi/benchmarksgame-rs/pull/46

These improved Rust programs have not yet been added to the benchmarksgame site. Previous entries are ranked at:

http://benchmarksgame.alioth.debian.org/u64q/performance.php...

Minor improvements to the Rust programs for "mandelbrot" and "binary-trees" are also awaiting review!

[kzrdude]

Would it be any worse to use `File::open("/dev/stdin")` there, so that it is safe code?

[mbrubeck]

Oh, that's a good idea. (It's unfortunate that neither my code nor yours is portable to non-Unix platforms like Windows.)

UPDATE: Pushed a commit to my latest PR to replace the unsafe `File::from_raw_fd` with your `File::open`. Thanks!

[acqq]

Thanks!

I like Rust for what it does in advancing the state of the art of the languages, but I also like how this example demonstrates how hard it is to avoid "unsafe" constructs and remain competitive.

https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src...

[mbrubeck]

For what it's worth, this alternate implementation has only one line of unsafe code (a call to the libc "memchr" function) and is only 9% slower than the fastest unsafe version:

https://github.com/mbrubeck/benchmarksgame-rs/blob/reverse_c...

It's very easy to write extremely fast safe Rust code. (The safe Rust version above is faster than the fastest C++ submission, on my computer.) Using "unsafe" for optimization is usually only helpful to get a few extra percent speedup in an inner loop. If this were production code rather than the benchmarks game, I'd probably ship the safe version.

[acqq]

Wonderful, thank you! Producing the safe versions which are that efficient is really the best argument for Rust that I can imagine.

[mbrubeck]

As an update, this pull request now removes most of the unsafe code:

https://github.com/TeXitoi/benchmarksgame-rs/pull/46

[mbrubeck]

Further update: I now have a Rust program that is 100% safe code and is also faster than any of the unsafe programs (including the C and C++ entries):

https://github.com/TeXitoi/benchmarksgame-rs/pull/55

[kibwen]

> one line of unsafe code (a call to the libc "memchr" function)

Is burntsushi's Rust implementation of memchr notably slower than libc's?

[burntsushi]

The rust-memchr crate uses libc's memchr if it's available and known to be fast. Otherwise, it falls back to a pure Rust implementation (written by bluss, not me).

I expect this to change once we get SIMD. ;-)

[mbrubeck]

> Is burntsushi's Rust implementation of memchr notably slower than libc's?

Not as far as I know. A lot of this benchmarksgame code has evolved slowly over time and hasn't been cleaned up yet to use "modern" crates and language features.