Skip to content

Commit

Permalink
api: add memmem implementation, initially from bstr
Browse files Browse the repository at this point in the history
This commit primarily adds vectorized substring search routines in
a new memmem sub-module. They were originally taken from bstr, but
heavily modified to incorporate a variant of the "generic SIMD"
algorithm[1]. The main highlights:

* We guarantee `O(m + n)` time complexity and constant space
  complexity.
* Two-Way is the primary implementation that can handle all cases.
* Vectorized variants handle a number of common cases.
* Vectorized code uses a heuristic informed by a frequency background
  distribution of bytes, originally devised inside the regex crate.
  This makes it more likely that searching will spend more time in the
  fast vector loops.

While adding memmem to this crate is perhaps a bit of a scope increase,
I think it fits well. It also puts a core primitive, substring
search, very low in the dependency DAG and therefore making it widely
available. For example, it is intended to use these new routines in the
regex, aho-corasick and bstr crates.

This commit does a number of other things, mainly as a result of
convenience. It drastically improves test coverage for substring search
(as compared to what bstr had), completely overhauls the benchmark suite
to make it more comprehensive and adds `cargo fuzz` support for all API
items in the crate.

Closes #58, Closes #72

[1] - http://0x80.pl/articles/simd-strfind.html#algorithm-1-generic-simd
  • Loading branch information
BurntSushi committed Apr 30, 2021
1 parent 78cc45d commit c3069cf
Show file tree
Hide file tree
Showing 85 changed files with 193,372 additions and 818 deletions.
2 changes: 2 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,8 @@ jobs:
CARGO: cargo
# When CARGO is set to CROSS, TARGET is set to `--target matrix.target`.
TARGET:
# Make quickcheck run more tests for hopefully better coverage.
QUICKCHECK_TESTS: 100000
runs-on: ${{ matrix.os }}
strategy:
matrix:
Expand Down
4 changes: 4 additions & 0 deletions Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -37,8 +37,12 @@ libc = { version = "0.2.18", default-features = false, optional = true }
[dev-dependencies]
quickcheck = { version = "1.0.3", default-features = false }

[profile.release]
debug = true

[profile.bench]
debug = true

[profile.test]
opt-level = 3
debug = true
60 changes: 34 additions & 26 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
memchr
======
The `memchr` crate provides heavily optimized routines for searching bytes.
This library provides heavily optimized routines for string search primitives.

[![Build status](https://github.com/BurntSushi/rust-memchr/workflows/ci/badge.svg)](https://github.com/BurntSushi/rust-memchr/actions)
[![](https://meritbadge.herokuapp.com/memchr)](https://crates.io/crates/memchr)
Expand All @@ -15,23 +15,15 @@ Dual-licensed under MIT or the [UNLICENSE](https://unlicense.org/).

### Overview

The `memchr` function is traditionally provided by libc, but its
performance can vary significantly depending on the specific
implementation of libc that is used. They can range from manually tuned
Assembly implementations (like that found in GNU's libc) all the way to
non-vectorized C implementations (like that found in MUSL).
* The top-level module provides routines for searching for 1, 2 or 3 bytes
in the forward or reverse direction. When searching for more than one byte,
positions are considered a match if the byte at that position matches any
of the bytes.
* The `memmem` sub-module provides forward and reverse substring search
routines.

To smooth out the differences between implementations of libc, at least
on `x86_64` for Rust 1.27+, this crate provides its own implementation of
`memchr` that should perform competitively with the one found in GNU's libc.
The implementation is in pure Rust and has no dependency on a C compiler or an
Assembler.

Additionally, GNU libc also provides an extension, `memrchr`. This crate
provides its own implementation of `memrchr` as well, on top of `memchr2`,
`memchr3`, `memrchr2` and `memrchr3`. The difference between `memchr` and
`memchr2` is that `memchr2` permits finding all occurrences of two bytes
instead of one. Similarly for `memchr3`.
In all such cases, routines operate on `&[u8]` without regard to encoding. This
is exactly what you want when searching either UTF-8 or arbitrary bytes.

### Compiling without the standard library

Expand All @@ -43,10 +35,9 @@ memchr links to the standard library by default, but you can disable the
memchr = { version = "2", default-features = false }
```

On x86 platforms, when the `std` feature is disabled, the SSE2
implementation of memchr will be used in compilers that support it. When
`std` is enabled, the AVX implementation of memchr will be used if the CPU
is determined to support it at runtime.
On x86 platforms, when the `std` feature is disabled, the SSE2 accelerated
implementations will be used. When `std` is enabled, AVX accelerated
implementations will be used if the CPU is determined to support it at runtime.

### Using libc

Expand All @@ -58,11 +49,11 @@ using `memchr` from libc is desirable and a vectorized routine is not otherwise
available in this crate, then enabling the `libc` feature will use libc's
version of `memchr`.

The rest of the functions in this crate, e.g., `memchr2` or `memrchr3`, are not
a standard part of libc, so they will always use the implementations in this
crate. One exception to this is `memrchr`, which is an extension commonly found
on Linux. On Linux, `memrchr` is used in precisely the same scenario as
`memchr`, as described above.
The rest of the functions in this crate, e.g., `memchr2` or `memrchr3` and the
substring search routines, will always use the implementations in this crate.
One exception to this is `memrchr`, which is an extension in `libc` found on
Linux. On Linux, `memrchr` is used in precisely the same scenario as `memchr`,
as described above.


### Minimum Rust version policy
Expand All @@ -77,3 +68,20 @@ version of Rust.

In general, this crate will be conservative with respect to the minimum
supported version of Rust.


### Testing strategy

Given the complexity of the code in this crate, along with the pervasive use
of `unsafe`, this crate has an extensive testing strategy. It combines multiple
approaches:

* Hand-written tests.
* Exhaustive-style testing meant to exercise all possible branching and offset
calculations.
* Property based testing through [`quickcheck`](https://github.com/BurntSushi/quickcheck).
* Fuzz testing through [`cargo fuzz`](https://github.com/rust-fuzz/cargo-fuzz).
* A huge suite of benchmarks that are also run as tests. Benchmarks always
confirm that the expected result occurs.

Improvements to the testing infrastructue are very welcome.
4 changes: 4 additions & 0 deletions bench/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,10 @@ harness = false
path = "src/bench.rs"

[dependencies]
bstr = "0.2.15"
criterion = "0.3.3"
memchr = { version = "*", path = ".." }
libc = "0.2.81"
regex = "1.4.5"
sliceslice = "0.2.1"
twoway = "0.2.1"
Loading

0 comments on commit c3069cf

Please sign in to comment.