3 ms·

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 fastes

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.
- mbrubeck 10y ago
  As an update, this pull request now removes most of the unsafe code: https://github.com/TeXitoi/benchmarksgame-rs/pull/46 https://github.com/TeXitoi/benchmarksgame-rs/pull/46
  - mbrubeck 10y ago
    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 https://github.com/TeXitoi/benchmarksgame-rs/pull/55
- deleted 10y ago
  [deleted]

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.

mbrubeck 10y ago
As an update, this pull request now removes most of the unsafe code: https://github.com/TeXitoi/benchmarksgame-rs/pull/46 https://github.com/TeXitoi/benchmarksgame-rs/pull/46
- mbrubeck 10y ago
  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 https://github.com/TeXitoi/benchmarksgame-rs/pull/55
deleted 10y ago
[deleted]