4 ms·

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,

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 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 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?test=revcomp http://benchmarksgame.alioth.debian.org/u64q/performance.php... Minor improvements to the Rust programs for "mandelbrot" and "binary-trees" are also awaiting review!

kzrdude 10y ago
Would it be any worse to use `File::open("/dev/stdin")` there, so that it is safe code?
- mbrubeck 10y ago
  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 10y ago
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/reverse_complement.rs https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src...
- mbrubeck 10y ago
  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_complement_bytes/src/reverse_complement.rs 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.
  - kibwen 10y ago
    > one line of unsafe code (a call to the libc "memchr" function) Is burntsushi's Rust implementation of memchr notably slower than libc's?
    - mbrubeck 10y ago
      > 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.
    - deleted 10y ago
      [deleted]
    - burntsushi 10y ago
      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. ;-)
  - acqq 10y ago
    Wonderful, thank you! Producing the safe versions which are that efficient is really the best argument for Rust that I can imagine.

kzrdude 10y ago

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

mbrubeck 10y ago
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 10y ago

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/reverse_complement.rs https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src...

mbrubeck 10y ago
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_complement_bytes/src/reverse_complement.rs 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.
- kibwen 10y ago
  > one line of unsafe code (a call to the libc "memchr" function) Is burntsushi's Rust implementation of memchr notably slower than libc's?
  - mbrubeck 10y ago
    > 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.
  - deleted 10y ago
    [deleted]
  - burntsushi 10y ago
    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. ;-)
- acqq 10y ago
  Wonderful, thank you! Producing the safe versions which are that efficient is really the best argument for Rust that I can imagine.