krep is a grep-compatible searcher that picks its own algorithm and uses SIMD

A grep-compatible searcher written in C with five algorithms behind one flag

krep describes itself as a high-performance string search utility for the command line, fast, multi-threaded and grep-compatible. That last word is the constraint that shapes everything else, because grep-compatible is not a marketing phrase but a promise about flags, exit statuses and output format. The feature list is a compact description of the design: smart algorithm selection across Boyer-Moore, KMP, Two-Way, Shift-Or and Aho-Corasick, SIMD acceleration for SSE2, AVX2, AVX-512 and NEON, memory-mapped I/O, and multi-threaded search across CPU cores. On top of that sit POSIX regular expressions and multiple pattern search, recursive directory search with globs, exclusions and .gitignore support, the familiar grep context flags, JSON Lines output for automation, and coloured output. The point of the algorithm list is that you do not have to pick one, since the default is a fixed string search and the tool chooses the strategy for you, with a flag available when you want to override it.

Installation is a clone, a make and a make install

The install path is deliberately plain, and there are two routes. On macOS it is a Homebrew formula. From source it is three commands.

# From source
git clone https://github.com/davidesantangelo/krep.git
cd krep
make
sudo make install

The requirements are a GCC or compatible C compiler, a POSIX system covering Linux, macOS and BSD, and pthread. Two build flags matter more than the rest for anyone shipping binaries. PORTABLE=1 produces distributable binaries, while NATIVE=1 tunes a build for your own CPU, and the readme warns you to run make clean before changing build flags, because the Makefile appends flags rather than replacing them. Published Linux x86-64 binaries use baseline SSE2, and source builds can enable the wider vectors the build machine supports. That distinction is the difference between a binary that runs on any x86-64 machine and one that assumes AVX-512 is present.

The Makefile detects the CPU and picks the widest instruction set

The build script shows the portability strategy in plain terms, since the SIMD flags are chosen by probing the host. The compiler defaults to gcc with -Wall -Wextra -O3 -std=c11 -pthread, and the CFLAGS line carries -flto, -funroll-loops and -finline-functions. The architecture is read from uname -m, and on x86_64 the script checks for AVX-512 support through /proc/cpuinfo on Linux and sysctl on macOS, then checks for AVX2 the same way. The result is a conditional ladder, where AVX-512 adds -mavx512f -mavx512bw -msse4.2 -mavx2, AVX2 alone adds -mavx2 -msse4.2, and the fallback is -msse4.2 which the comment describes as widely supported on x86-64. On arm64 the flag is -D__ARM_NEON, with a note that GCC might enable NEON automatically but that the explicit flag is safer, and aarch64 is handled in the same family. The NATIVE=1 path adds -march=native and -mtune=native, and PORTABLE=1 suppresses the host x86 instruction set flags.

Grep compatibility is a list of specific flags, not a claim

The option list reads like grep's own manual, and that is the point. The context and reporting flags are -A, -B and -C for context after, before or around matches, -n for line numbers, -o to print only the matched parts, -c to count matching lines only, -l and -L for files with and without matches, and -q for exit status only. Pattern handling covers -e for a repeatable pattern flag, -f to read patterns from a file with - meaning standard input, -m to cap matching lines per file, -E for POSIX extended regular expressions and -F for fixed strings, which is the default. Then there are -i for case-insensitive search and -w for whole words only. The invocation grammar is spelled out too, with a pattern and a file or directory, repeated -e patterns, -f for a pattern file, and -s to search inside a string rather than a file. That last one is what lets the tool be used as a library-like helper inside a script rather than only against files.

Recursive search is where the tool goes beyond plain grep

The recursive mode is the part that turns this into something other than a faster grep, and the flags are layered on top of -r. You can include or exclude paths with --glob and --exclude, you can include hidden files with --hidden, and you can make the traversal respect .gitignore with --gitignore. The examples show the combinations, with a recursive fixed string search over a project directory, a recursive search that respects .gitignore, and one that filters by a glob while excluding a vendor directory.

krep -r --glob '*.c' --exclude '*/vendor/*' "TODO" .

Two of the reporting modes are specially useful in a script, since -q, -l and -L stop after the first match. The readme is explicit about the consequence, that their match totals are intentionally capped at one per searched file, which is a deliberate choice rather than an accounting bug. That is the kind of detail that matters when you compare the --stats output of a quiet run against a full run and assume something is wrong. There is also --stats, which prints a summary to standard error, so the counts never contaminate the search output itself.

JSON Lines output exists so the tool fits into a pipeline

Automation is an explicit goal in the feature list, and the JSON Lines mode is how it is reached. The flag is --json, with --jsonl given as an equivalent form, and the example shows it applied to a single file.

krep --json "needle" ./src/main.c

JSON Lines is the right choice for this purpose because one object per line survives being piped into line-oriented tools without needing a parser that can hold a whole document in memory, which matters when the matches are in the hundreds of thousands. The other end of the automation story is the pattern-from-stdin form, which lets a generator feed a set of patterns into a search without a temporary file.

echo 'pattern' | krep -f - target.txt

The readme also documents what the statistics do not measure, which is unusual and useful. The --stats output reports matches encountered, input byte totals describe the size of the supplied file or buffer rather than physical I/O, and standard input is buffered before searching. That last point changes how you read the numbers, because a search over piped input measures what was buffered rather than what was read from the device.

The 3.1.0 release and how the project tests itself

The recent release notes describe what changed rather than what is planned. Version 3.1.0 adds two-byte SIMD filtering for literals, linear-time line numbering and JSON output, and early exit for existence checks, and the readme points at a performance report for measurements against 3.0.2 that includes the hardware used, the raw samples and the limitations of the comparison. The test targets show what the project treats as worth protecting. The ci target runs unit, protected-page, directory and CLI tests and needs Python 3, and the sanitize target rebuilds and tests with AddressSanitizer and UndefinedBehaviorSanitizer and needs Clang. The readme warns you to run make clean and make again afterwards, because sanitizer instrumentation leaves you with a debug build rather than the optimized one. There is also a bench-release target that generates a local dataset with no download required, and a script that compares against a baseline binary over several runs. The protected-page test is the interesting one, since it covers the case where the searcher reads memory-mapped pages it must not write to.

Where krep is the wrong choice

The first wrong case is a workload with huge files and trivial patterns, because a fixed string search over a multi-gigabyte file is already handled well by the system's own tools and the multi-threading helps only when there is more than one file to work on. The second is a team that needs the full breadth of grep's dialect and its edge behaviour, since krep covers the common flags and POSIX regular expressions but the option list is not a complete reimplementation of everything grep does. The third is a workflow that depends on a specific output format from grep, since the colouring, the JSON Lines mode and the --stats output to standard error all change what a downstream script sees. The fourth is a build environment without a C compiler or without pthread, since those are the stated requirements and there is no fallback build. The fifth is a machine where you cannot rely on the SIMD flags matching the host, which is why the published Linux binaries use baseline SSE2, and why a distribution package built with NATIVE=1 on a developer machine would be a mistake. The sixth is anyone who needs a program to be read and adapted quickly, since a hand-optimised C codebase with SIMD intrinsics is not the place to look for a tool to modify.

Editorial conclusion

People who search large trees or large files from a terminal and want the same command surface with more speed, plus the extras that grep lacks such as .gitignore-aware recursion and JSON Lines output, are the people krep is for. It is the wrong choice for a workload that is already fast enough with the system's grep, since a new binary is a new thing to install and maintain on every machine you use, and it is the wrong choice for a team that needs a stable, widely understood tool rather than a young project. Check three things before you commit: that the published Linux x86-64 binary will run on your hardware, since it uses baseline SSE2 while a native build assumes AVX2 or AVX-512 is present, that your scripts do not depend on grep's exact output or exit status conventions, since coloured output, the JSON Lines mode and the statistics written to standard error all change what a downstream consumer sees, and how the multi-threading behaves on your file counts, since the readme is explicit that the byte totals describe the supplied file or buffer rather than physical I/O. The licence is BSD-2-Clause, the last push was on 2026-09-16, and the newest release is v3.1.0 from the same day, with the project author named as Davide Santangelo.

Frequently asked questions

Official sources

1. davidesantangelo/krep on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases