Data-Structure on CuriousCoding

Route Planning using Customizable Contraction Hierarchies

Mon, 02 Mar 2026 00:00:00 +0100

Table of Contents

1 Problem Statement: Customizable Route Planning (CRP)
2 Contraction Hierarchies (CH)
- 2.1 Classic Contraction Hierarchies
- 2.2 Customizable Contraction Hierarchies (CCH)
3 Analogy with trees
4 Shortest Paths in CHs
5 Parents: Faster Shortest Paths in CCHs
6 Input Graph
7 Initial Algorithm
- 7.1 Permute input
- 7.2 Chordal Completion and Parents
- 7.3 Customize
- 7.4 Query
8 Optimizing things
- 8.1 Binary searching in find_edge
- 8.2 HashMap of edges
- 8.3 Ranges of neighbours
- 8.4 Linear scan
- 8.5 Proper query algorithm
- 8.6 Pruning edges
- 8.7 Pruning
- 8.8 Unconditional edge relaxing
- 8.9 Early edge break
- 8.10 DFS-ordering the nodes
- 8.11 Not inclining queries
9 Some stats
10 Serializing the final structure
11 Merging adjacent edges
- 11.1 Perf stat
- 11.2 All ranges are multiples of 8
- 11.3 All ranges have size 8
- 11.4 Finding the bottleneck
12 Bugfixing
13 Further ideas
- 13.1 Failed: Doubling the graph
- 13.2 Edge pruning
- 13.3 Failed: Expanding a node and its parent in parallel
14 Current best results
- 14.1 Bottleneck
15 TODO

These are some notes on customizable contraction hierarchies, based on talks with Michael Zündorf and the survey paper by Bläsius, Buchhold, Wagner, Zeitz, and Zündorf (2025).

Wheeler graphs

Thu, 26 Feb 2026 00:00:00 +0100

Table of Contents

1 Deterministic Finite Automaton (DFA)
2 Wheeler-DFA
3 Linear graphs: Prefix array
4 De Bruijn graphs are Wheeler
5 Not all DFAs are Wheeler
6 Locating patterns via binary search
7 Locating patterns via the BOSS table

These are some notes on Wheeler DFAs after chatting with Nicola Prezza¹ and others from the RAVEN lab at DSB 2026 in Venice.

1 Deterministic Finite Automaton (DFA) Link to heading

A DFA is a graph where edges are labelled by characters. Each node can have at most one outgoing edge with each label. (Otherwise it would be non-deterministic.)

QuadRank: Engineering a High-Throughput Rank

Wed, 18 Feb 2026 00:00:00 +0100

Binary Rank: Problem statement Link to heading

Input: a many-GB text $T = t_0\dots t_{n-1}$ of $n$ bits.
Queries: given $q$, find

\begin{equation*} \newcommand{\rank}{\mathsf{rank}} \rank(q) := \sum_{0\leq i< q} t_i. \end{equation*}

$T = \underline{\texttt{1001001}}\texttt{110010100}$
- $\rank(0) = 0$
- $\rank(7) = 3$
- $\rank(16) = 7$
Why? Occurrences table in FM-index.

Naive solutions Link to heading

Linear scan:
- $O(n/w)$ time using $w$ bit popcount, no space overhead.

Precompute all 64-bit answers $r_i := \rank(i)$:
- $O(1)$ time, $64\times$ overhead.

Middle-ground: block-based offsets Link to heading

Use $B=512$ bit blocks, and store all $b_j := \rank(j\cdot B)$.

Query $q = j\cdot B + q’$: $\rank(q) = b_j + \sum_{jB\leq i < jB+q’} t_i$.
$O(B/w) = O(512/64) = O(1)$ time.
$64/512 = 12.5\%$ space overhead.
2 cache misses:
- in $n/8$ bit array: offset $b_j$
- in $n$ bit array: block $j$ bits

Reducing overhead: PastaWide [and others] Link to heading

2 levels:
- L2 with 16-bit delta every block: 3.125% overhead
- L1 with 64-bit offset every 128 blocks: 0.1% overhead

Reducing cache misses: SPIDER Link to heading

Inline the 16-bit L2 deltas bits into each cache line
- Remaining 0.1% overhead L1 array fits in cache.

Reducing the popcount: Pairing Link to heading

Delta is to the middle instead of start of a block.
- Count only 256 bits in first or second half of block.

All together now: BiRank Link to heading

Inline 16-bit deltas
Pairing
32-bit reduced L1 offsets: 0.05% overhead
- Low 11 bits are stored in deltas
- Input up to $2^{43}$ bits
- 16 MiB cache supports 32 GiB input

QuadRank: Engineering a High Throughput Rank

Thu, 29 Jan 2026 00:00:00 +0100

Table of Contents

Abstract
1 Introduction
2 Background
- 2.1 Further implementations
3 BiRank
- 3.1 Variants
4 QuadRank
- 4.1 Variants
5 Results
- 5.1 BiRank
- 5.2 QuadRank
6 Conclusion
7 Acknowledgements
8 Code snippets
9 Pairing superblocks
10 Additional results
- 10.1 Throughput for small inputs
- 10.2 AMD EPYC evals
11 QuadFm: A Batching FM-index
- 11.1 Results

\[\newcommand{\rank}{\mathsf{rank}} \newcommand{\rankone}{\mathsf{rank}} \newcommand{\rankall}{\mathsf{rank_4}}\]

This is the text for the QuadRank paper (Groot Koerkamp 2026) (PDF, arxiv). See also the reveal-js slides, plain slide content, and the github code.

Elias-Fano

Sun, 25 Jan 2026 00:00:00 +0100

Range-minimum queries

Sun, 25 Jan 2026 00:00:00 +0100

Rank

Sun, 25 Jan 2026 00:00:00 +0100

Select

Sun, 25 Jan 2026 00:00:00 +0100

Overview of static data structures

Wed, 17 Dec 2025 00:00:00 +0100

Table of Contents

1 Classification of static data structures
2 Space lower bounds and practical approaches
- 2.1 Rank
- 2.2 Rank + Select
- 2.3 Minimal perfect hash function (MPHF)
- 2.4 TODO Monotone MPHF
- 2.5 TODO Order-preserving MPHF
- 2.6 Static retrieval: Static function with static values
- 2.7 Updatable retrieval: Static function with mutable values
- 2.8 Static set (membership)
- 2.9 Static ordered set
- 2.10 Static dictionary: static keys and values
- 2.11 Updatable dictionary with mutable values
- 2.12 TODO Dynamic dictionary with mutable keys and values
- 2.13 TODO Static filter
- 2.14 TODO Ordered static/updatable/dynamic dictionary?
3 Summary table

\[ \newcommand{\K}{\mathbb K} \newcommand{\V}{\mathbb V} \newcommand{\c}[1]{\mathbf{\mathsf{#1}}} \]

Thoughts on "Static Retrieval Revisited"

Tue, 04 Nov 2025 00:00:00 +0100

Table of Contents

1 Problem definitions
2 Optimal solutions
3 Why an overhead is necessary
4 Augmented Retrieval

These are some summarizing notes and thoughts on “Static Retrieval Revisited: To Optimality and beyond” by Hu, Kuszmaul, Liang, Yu, Zhang, and Zhou.

1 Problem definitions Link to heading

Static Retrieval. Given $n$ keys $X\subseteq U$ and $n$ $v$-bit values $f(X) \in [2^v]$, encode $f: X\to [2^v]$. The goal is use a minimal number of bits on top of the trivial $nv$ lower bound, while allowing efficient queries.

Binary search variants and the effects of batching

Wed, 12 Feb 2025 00:00:00 +0100

Table of Contents

1 Optimizing Binary Search And Interpolation Search
- 1.1 Problem statement
- 1.2 Inspiration and background
- 1.3 Benchmarking setup
2 Binary search
- 2.1 Branchless search
- 2.2 Explicit prefetching
- 2.3 Batching
- 2.4 A note on power-of-two array sizes
3 Eytzinger
- 3.1 Naive implementation
- 3.2 Prefetching
- 3.3 Branchless Eytzinger
- 3.4 Batched Eytzinger
  - 3.4.1 Non-prefetched
  - 3.4.2 Prefetched
4 Eytzinger or BinSearch?
5 Memory efficiency – parallel search and comparison to S-trees
6 Interpolation search
7 Conclusion and takeaways

1 Optimizing Binary Search And Interpolation Search Link to heading

This blogpost is a preliminary of the post on static search trees. We will be looking into binary search and how it can be optimized using different memory layouts (Eytzinger), branchless techniques and careful use of prefetching. In addition, we will explore batching. Our language of choice will be Rust.

Thoughts on Consensus MPHF and tiny pointers

Wed, 12 Feb 2025 00:00:00 +0100

Table of Contents

1 Consensus
- 1.1 Consensus-RecSplit
2 IDEA: Consensus-PtrHash
3 Tiny pointers and optimal open addressing hash tables

These are some thoughts on the Consensus-based MPHF presented in Lehmann et al. (2025), and how this could be applied to PtrHash:

Lehmann, Hans-Peter, Peter Sanders, Stefan Walzer, and Jonatan Ziegler. 2025. “Combined Search and Encoding for Seeds, with an Application to Minimal Perfect Hashing.” arXiv; arXiv. https://doi.org/10.48550/ARXIV.2502.05613.

Below are also some thoughts on the papers on tiny pointers, used to achieve hash tables with load factors very close to 1: Bender et al. (2021), Farach-Colton, Krapivin, and Kuszmaul (2024).

PtrHash: Minimal Perfect Hashing at RAM Throughput

Mon, 03 Feb 2025 00:00:00 +0100

Table of Contents

Abstract
1 Introduction
2 Related work
3 PtrHash
- 3.1 Overview
- 3.2 Construction
- 3.3 Bucket Assignment Functions
- 3.4 Remapping using CacheLineEF
4 Results
- 4.1 Construction
  - 4.1.1 Bucket Functions
  - 4.1.2 Tuning Parameters for Construction
  - 4.1.3 Remap
- 4.2 Comparison to Other Methods
5 Conclusions and Future Work
Appendix A: Query Throughput
Appendix B: Sharding
- Evaluation

This is the HTML version of my SEA 2025 paper on PtrHash (DOI, PDF). The original development-log can be found here.

Static search trees: 40x faster than binary search

Wed, 18 Dec 2024 00:00:00 +0100

Table of Contents

1 Introduction
- 1.1 Problem statement
- 1.2 Motivation
- 1.3 Recommended reading
- 1.4 Binary search and Eytzinger layout
- 1.5 Hugepages
- 1.6 A note on benchmarking
- 1.7 Cache lines
- 1.8 S-trees and B-trees
2 Optimizing find
- 2.1 Linear
- 2.2 Auto-vectorization
- 2.3 Trailing zeros
- 2.4 Popcount
- 2.5 Manual SIMD
3 Optimizing the search
- 3.1 Batching
- 3.2 Prefetching
- 3.3 Pointer arithmetic
  - 3.3.1 Up-front splat
  - 3.3.2 Byte-based pointers
  - 3.3.3 The final version
- 3.4 Skip prefetch
- 3.5 Interleave
4 Optimizing the tree layout
- 4.1 Left-tree
- 4.2 Memory layouts
- 4.3 Node size $B=15$
  - 4.3.1 Data structure size
- 4.4 Summary
5 Prefix partitioning
- 5.1 Full layout
- 5.2 Compact subtrees
- 5.3 The best of both: compact first level
- 5.4 Overlapping trees
- 5.5 Human data
- 5.6 Prefix map
- 5.7 Summary
6 Multi-threaded comparison
7 Conclusion
- 7.1 Future work
  - 7.1.1 Branchy search
  - 7.1.2 Interpolation search
  - 7.1.3 Packing data smaller
  - 7.1.4 Returning indices in original data
  - 7.1.5 Range queries
  - 7.1.6 Sorting queries
  - 7.1.7 Suffix array searching

In this post, we will implement a static search tree (S+ tree) for high-throughput searching of sorted data, as introduced on Algorithmica. We’ll mostly take the code presented there as a starting point, and optimize it to its limits. For a large part, I’m simply taking the ‘future work’ ideas of that post and implementing them. And then there will be a bunch of looking at assembly code to shave off all the instructions we can. Lastly, there will be one big addition to optimize throughput: batching.

FM-index implementations

Wed, 02 Oct 2024 00:00:00 +0200

Table of Contents

A note on SDSL versions

Here I’ll briefly list some FM-index and related implementations around the web. Implementations seem relatively inconsistent, mostly because the FM-index is more of a ‘wrapper’ type around a given Burrows-Wheeler-transform and an occurrences list implementation. Both can be implemented in various ways. In particular occurrences should be stored using a wavelet tree for optimal compression.

The nucleic-acid repo contains a completely unoptimised version.
The Rust-bio crate contains a generic FM-index. It stores a sampled occurrences array, so that space is relatively small but lookups take $O(k)$ time for sampling factor $k$.
SDSL-lite contains a wavelet tree and compressed suffix array implementation based on it, that provides the same functionality as an FM-index.
There is the Quad Wavelet Tree (QWT) Rust crate (Ceregini, Kurpicz, and Venturini 2024). This uses a 4-ary tree instead of the usual binary wavelet tree, and improves latency by around a factor 2 over SDSL wavelet trees.
Dominik Kempa has the Faster-Minuter index (Gog et al. 2019) that contains an improved wavelet tree as well.
GEM-Cutter contain a GPU implementation of the FM-index (Chacon et al. 2015).
There is also RopeBWT3 (Li 2024), which is basically a run-length compressed BWT with a B+ tree on top for fast queries.
AWRY

A note on SDSL versions Link to heading

github:simongog/sdsl is the original, with last commit in 2013.
github:simongog/sdsl-lite is v2, with last commit in 2019, and seems the most used currently.
github:xxsds/sdsl-lite is v3 and seems to be actively maintained at the time of writing (Jan 2025), and is recommended by the original developers. From a quick glance, I think it’s somewhat restructured and truly a v3, not just a v2.1. However, it seems to be much less popular.
github:vgteam/sdsl-lite is a fork of the original sdsl-lite, with, I think, a number of small bug fixes and some updates for recent compiler versions.

Then there are also some rust versions:

String algorithm visualizations

Tue, 08 Nov 2022 00:00:00 +0100

Select the algorithm to visualize
Click the buttons, or click the canvas and use the indicated keys

Suffix-array construction is explained here and BWT is explained here.

Source code is on GitHub.

Algorithm
String
Query

Delay (s)

Data-Structure on CuriousCoding

Route Planning using Customizable Contraction Hierarchies

Wheeler graphs

1 Deterministic Finite Automaton (DFA) Link to heading

QuadRank: Engineering a High-Throughput Rank

Binary Rank: Problem statement Link to heading

History Link to heading

Naive solutions Link to heading

Middle-ground: block-based offsets Link to heading

Reducing overhead: PastaWide [and others] Link to heading

Reducing cache misses: SPIDER Link to heading

Reducing the popcount: Pairing Link to heading

All together now: BiRank Link to heading

What is fast? Link to heading

QuadRank: Engineering a High Throughput Rank

Recent results on hash tables

Elias-Fano

References Link to heading

Range-minimum queries

References Link to heading

Rank

References Link to heading

Select

References Link to heading

Overview of static data structures

Thoughts on "Static Retrieval Revisited"

1 Problem definitions Link to heading

Binary search variants and the effects of batching

1 Optimizing Binary Search And Interpolation Search Link to heading

Thoughts on Consensus MPHF and tiny pointers

PtrHash: Minimal Perfect Hashing at RAM Throughput

Static search trees: 40x faster than binary search

FM-index implementations

A note on SDSL versions Link to heading

String algorithm visualizations