Data-Structure on CuriousCoding

Range Minimum Queries

Mon, 11 May 2026 00:00:00 +0200

Table of Contents

1 Naive
- 1.1 Compute on-the-fly
- 1.2 Precompute everything
2 Space lower bounds
3 Sparse Table: $O(1)$ queries, $O(n \log_2 n)$ words
4 Segment Tree: $O(\log n)$ queries, $O(n)$ words
5 Blocks: $O(s)$ queries, $O(n/s \log n)$ words
6 Cartesian Trees: $O(1)$ queries, $O(n)$ words
7 Recursive Cartesian Trees: $O(1)$ queries, $2n+o(n)$ bits
8 Blackboard

\[ \DeclareMathOperator*{\argmin}{arg\,min} \newcommand{\rmq}{\mathsf{rmq}} \]

These notes are based on slides by Florian Kurpicz and the paper by Fischer and Heun (2011) that introduces a number of optimal implementations.

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

Kurpicz (2022)
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

Laws et al. (2024)
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

Gottlieb and Reinert (2025)
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 from SPIDER (Laws et al. 2024)
Pairing from Gottlieb and Reinert (2025)
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 Cache misses per query
- 10.2 Throughput for small inputs
- 10.3 AMD EPYC evals
11 QuadFm: A Batching FM-index
- 11.1 Results
12 Further code optimization ideas

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

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.

QuickHeap: the fastest priority queue

Mon, 11 Aug 2025 00:00:00 +0200

Table of Contents

1 Background
2 Literature on Quickheaps
3 Bucket-based implementation
- Data structure
- Push
- Pop
- Partition
4 Results
5 Conclusion

Backlinks: bsky, X, hacker news, lobste.rs

A preprint on the SimdQuickHeap (github:RagnarGrootKoerkamp/QuickHeap) with the latest results can now be found on arXiv (DOI, PDF):

40x Faster Binary Search

Sun, 20 Jul 2025 00:00:00 +0200

Ragnar {Groot Koerkamp} Link to heading

Did IMO & ICPC; currently head-of-jury for NWERC.
Some time at Google.
Quit and solved all of projecteuler.net (700+) during Covid.
Just finished PhD on high throughput bioinformatics @ ETH Zurich.
- Lots of sequenced DNA that needs processing.
- Many static datasets, e.g. a 3GB human genome.
- Revisiting basic algorithms and optimizing them to the limit.
- Good in theory $\neq$ fast in practice.

Problem Statement Link to heading

Input: a static sorted list of 32 bit integers.
Queries: given $q$, find the smallest value in the list $\geq q$.

1
2
3
4
5
6


trait SearchIndex {
 // Initialize the data structure.
 fn new(sorted_data: &[u32]) -> Self;
 // Return the smallest value >=q.
 fn query(&self, q: u32) -> u32;
}

Why? E.g. searching through a suffix array.
Previous work on Algorithmica:
en.algorithmica.org/hpc/data-structures/s-tree
This work: curiouscoding.nl/posts/static-search-tree

Binary Search: complexity $O(\lg n)$ Link to heading

Compare $q=5$ with the middle element $x$.
Recurse on left half if $q\leq x$, right half if $q>x$.
End when 1 element left after $\lceil\lg_2(n+1)\rceil$ steps.

Binary Search: latency is more than $O(\lg n)$ Link to heading

Array Indexing: $O(n^{0.35})$ latency! Link to heading

Heap Layout: efficient caching + prefetching Link to heading

Binary search: top of tree is spread out; each cache line has 1 value.
Eytzinger layout: top layers of tree are clustered in cache lines.
- Also allows prefetching!

Heap Layout: close to array indexing! Link to heading

Static Search Trees / B-trees Link to heading

Fully use each cache line.

1
2
3
4
5
6


#[repr(align(64))] // Each block fills exactly one 512-bit cache line.
struct Block { data: [u32; 16] }
struct Tree {
 tree: Vec<Block>, // Blocks.
 offsets: Vec<usize>, // Index of first block in each layer.
}

Static Search Trees: Slower than Eytzinger?! Link to heading

Up next: assembly-level optimizations :) Link to heading

Optimizing `find`: linear scan baseline Link to heading

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


fn find_linear(block: &Block, q: u32) -> usize {
 for i in 0..N {
 if block.data[i] >= q {
 // Early break causes branch mispredictions
 // and prevents auto-vectorization!
 return i;
 }
 }
 return N;
}

Optimizing `find`: auto-vectorization Link to heading

1
2
3
4
5
6
7
8
9


fn find_count(block: &Block, q: u32) -> usize {
 let mut count = 0;
 for i in 0..N {
 if block.data[i] < q {
 count += 1;
 }
 }
 count
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


vmovdqu (%rax,%rcx), %ymm1 ; load data[..8]
vmovdqu 32(%rax,%rcx), %ymm2 ; load data[8..]
vpbroadcastd %xmm0, %ymm0 ; 'splat' the query value
vpmaxud %ymm0, %ymm2, %ymm3 ; v
vpcmpeqd %ymm3, %ymm2, %ymm2 ; v
vpmaxud %ymm0, %ymm1, %ymm0 ; v
vpcmpeqd %ymm0, %ymm1, %ymm0 ; 4x compare query with values
vpackssdw %ymm2, %ymm0, %ymm0 ;
vpcmpeqd %ymm1, %ymm1, %ymm1 ; v
vpxor %ymm1, %ymm0, %ymm0 ; 2x negate result
vextracti128 $1, %ymm0, %xmm1 ; v
vpacksswb %xmm1, %xmm0, %xmm0 ; v
vpshufd $216, %xmm0, %xmm0 ; v
vpmovmskb %xmm0, %ecx ; 4x extract mask
popcntl %ecx, %ecx

Optimizing `find`: popcount Link to heading

1
2
3
4
5
6
7


#![feature(portable_simd)]
fn find_popcount(block: &Block, q: i32) -> usize {
 let data: Simd<i32, N> = Simd::from_slice(&block.data[0..N]);
 let q = Simd::splat(q);
 let mask = data.simd_lt(q); // x[i] < q
 mask.to_bitmask().count_ones() // count_ones
}

1
2
3
4
5
6
7
8


vpcmpgtd (%rsi,%rdi), %ymm0, %ymm1
vpcmpgtd 32(%rsi,%rdi), %ymm0, %ymm0
vpackssdw %ymm1, %ymm0, %ymm0 ; interleave 16bit low halves
vextracti128 $1, %ymm0, %xmm1 ; 1
vpacksswb %xmm1, %xmm0, %xmm0 ; 2
vpshufd $216, %xmm0, %xmm0 ; 3 unshuffle interleaving
vpmovmskb %xmm0, %edi ; 4 instructions to extract bitmask
popcntl %edi, %edi

Optimizing `find`: manual `movemask_epi8` Link to heading

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


fn find_manual(block: &Block, q: i32) -> usize { // i32 now!
 let low: Simd<i32, 8> = Simd::from_slice(&self.data[0..N / 2]);
 let high: Simd<i32, 8> = Simd::from_slice(&self.data[N / 2..N]);
 let q = Simd::<i32, 8>::splat(q);
 let mask_low = q_simd.simd_gt(low ); // compare with low half
 let mask_high = q_simd.simd_gt(high); // compare with high half
 let merged = _mm256_packs_epi32(mask_low, mask_high); // interleave
 let mask: i32 = _mm256_movemask_epi8(merged); // movemask_epi8!
 mask.count_ones() as usize / 2 // correct for double-counting
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 vpcmpgtd (%rsi,%rdi), %ymm0, %ymm1 ; 1 cycle, in parallel
 vpcmpgtd 32(%rsi,%rdi), %ymm0, %ymm0 ; 1 cycle, in parallel
 vpackssdw %ymm0, %ymm1, %ymm0 ; 1 cycle
-vextracti128 $1, %ymm0, %xmm1 ;
-vpacksswb %xmm1, %xmm0, %xmm0 ;
-vpshufd $216, %xmm0, %xmm0 ;
-vpmovmskb %xmm0, %edi ; 4 instructions emulating movemask_epi16
+vpmovmskb %ymm0, %edi ; 2 cycles movemask_epi8
 popcntl %edi, %edi ; 1 cycle
+ ; /2 is folded into pointer arithmetic

The results: branchless is great! Link to heading

Throughput, not latency Link to heading

Batching: Many queries in parallel Link to heading

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-fn query (&self, q : u32 ) -> u32 {
+fn batch<const B: usize>(&self, qs: &[u32; B]) -> [u32; B] {
- let mut k = 0 ; // current index
+ let mut k = [0; B]; // current indices
 for [o, _o2] in self.offsets.array_windows() { // walk down the tree
+ for i in 0..B {
 let jump_to = self.node(o + k[i]).find(qb[i]); // call `find`
 k[i] = k[i] * (B + 1) + jump_to; // update index
+ }
 }

 let o = self.offsets.last().unwrap();
+ from_fn(|i| {
 let idx = self.node(o + k[i]).find(qb[i]);
 self.tree[o + k[i] + idx / N].data[idx % N] // return value
+ })
 }

Batching: up to 2.5x faster! Link to heading

Prefetching Link to heading

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


 fn batch<const B: usize>(&self, qs: &[u32; B]) -> [u32; B] {
 let mut k = [0; B]; // current indices
 for [o, o2] in self.offsets.array_windows() { // walk down the tree
 for i in 0..B {
 let jump_to = self.node(o + k[i]).find(qb[i]); // call `find`
 k[i] = k[i] * (B + 1) + jump_to; // update index
+ prefetch_index(&self.tree, o2 + k[i]); // prefetch next layer
 }
 }

 let o = self.offsets.last().unwrap();
 from_fn(|i| {
 let idx = self.node(o + k[i]).find(qb[i]);
 self.tree[o + k[i] + idx / N].data[idx % N] // return value
 })
 }

Prefetching: 30% faster again! Link to heading

Optimizing pointer arithmetic: more gains Link to heading

Convert all pointers to byte units, to avoid conversions.

Interleaving: more pressure on the RAM, -20% Link to heading

Interleave multiple batches at different iterations.

Tree layout: internal nodes store minima Link to heading

For query 5.5, we walk down the left subtree.
Returning 6 reads a new cache line.

Tree layout: internal nodes store maxima Link to heading

For query 5.5, we walk down the middle subtree.
Returning 6 reads the same cache line.

Tree layout: another 10% gained! Link to heading

Conclusion Link to heading

With 4GB input: 40x speedup!

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. 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 online 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

Range Minimum Queries

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

Overview of static data structures

Thoughts on "Static Retrieval Revisited"

1 Problem definitions Link to heading

QuickHeap: the fastest priority queue

40x Faster Binary Search

Ragnar {Groot Koerkamp} Link to heading

Problem Statement Link to heading

Binary Search: complexity \(O(\lg n)\) Link to heading

Binary Search: latency is more than \(O(\lg n)\) Link to heading

Array Indexing: \(O(n^{0.35})\) latency! Link to heading

Heap Layout: efficient caching + prefetching Link to heading

Heap Layout: close to array indexing! Link to heading

Static Search Trees / B-trees Link to heading

Static Search Trees: Slower than Eytzinger?! Link to heading

Up next: assembly-level optimizations :) Link to heading

Optimizing find: linear scan baseline Link to heading

Optimizing find: auto-vectorization Link to heading

Optimizing find: popcount Link to heading

Optimizing find: manual movemask_epi8 Link to heading

The results: branchless is great! Link to heading

Throughput, not latency Link to heading

Batching: Many queries in parallel Link to heading

Batching: up to 2.5x faster! Link to heading

Prefetching Link to heading

Prefetching: 30% faster again! Link to heading

Optimizing pointer arithmetic: more gains Link to heading

Interleaving: more pressure on the RAM, -20% Link to heading

Tree layout: internal nodes store minima Link to heading

Tree layout: internal nodes store maxima Link to heading

Tree layout: another 10% gained! Link to heading

Conclusion 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

Optimizing `find`: linear scan baseline Link to heading

Optimizing `find`: auto-vectorization Link to heading

Optimizing `find`: popcount Link to heading

Optimizing `find`: manual `movemask_epi8` Link to heading