Hpc on CuriousCoding

Sassy: fuzzy searching DNA sequences using SIMD

Thu, 04 Jun 2026 00:00:00 +0200

Table of Contents

1 Why should you care?
2 Using Sassy
- 2.1 The CLI
- 2.2 Rust library
- 2.3 Python bindings
- 2.4 C and R bindings
3 Problem statement: Approximate String Matching
- 3.1 Overhang: when the pattern extends beyond the read
4 Some background
5 The algorithm
- 5.1 SIMD
- 5.2 Sassy2
6 Results
- 6.1 Sassy1
- 6.2 Sassy2
- 6.3 Applications

Discuss on reddit.

Sassy is a tool for quickly searching short DNA patterns across large inputs that Rick Beeloo and myself have been working on over the past year. It just got published (Beeloo and Groot Koerkamp 2026b) (PDF, DOI), and this blog post briefly outlines some possible applications and how we developed it. See also the GitHub readme and the slides for my RECOMB-Seq talk, which loosely form the basis for this post.

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

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.

History Link to heading

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

What is fast? Link to heading

Latency: 80 ns/q

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}}\]

Trying to understand DDR memory

Tue, 20 Jan 2026 00:00:00 +0100

Table of Contents

1 Questions
2 A load of articles/blogs/pages to read
- 2.1 Wikipedia articles
- 2.2 More posts
- 2.3 Notes
- 2.4 My own RAM
- 2.5 Continued notes
- 2.6 Address mapping notation
- 2.7 Intel spec
- 2.8 Rank interleaving
- 2.9 Nontemporal reads/writes
3 reMap: using Performance counters
4 Sudoku
- 4.1 Step 1: DRAM addressing functions
- 4.2 Step 2: row/column bits
- 4.3 Step 3: validation
- 4.4 Step 4: which function is what?
- 4.5 Refreshes
- 4.6 Consecutive Accesses
5 Sudoku, now with only 1 DIMM
- 5.1 setup
- 5.2 1. reverse functions
- 5.3 2. identify bits
- 5.4 3. validate mapping
- 5.5 4. decompose functions
6 Final results
7 decode-dimms
- 7.1 Bank groups
- 7.2 Refresh
- 7.3 Random access throughput
8 CPU benchmarks
- 8.1 cpu-benchmarks
  - 8.1.1 random access throughput 1 DIMM
  - 8.1.2 random access throughput 2 DIMM
- 8.2 memory-read-experiment
  - 8.2.1 strided reading 1 DIMM
  - 8.2.2 strided reading 2 DIMM
9 tinymembench
10 Remaining questions

These are chronological (and thus, only lightly organized) notes on my attempt to understand how DDR4 and DDR5 RAM memory work.

Quotes from "The Evolution of Mathematical Software"

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

These are some nice quotes from “The Evolution of Mathematical Software”, Turing Lecture by the 2021 Turing Award winner Jack J. Dongarra, which talks about algorithm and software development in the context of ever improving hardware.

a large infrastructure of mathematical libraries […] that must be mainted, ported, and enhanced for many years to come if the value of the application codes that depend on it are to be preserved and extended. The software that encapsulates all this time, energy, and thought, routinely outlasts the hardware it was originally designed to run on.

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):

Chunking for Fasta Parsing

Wed, 06 Aug 2025 00:00:00 +0200

Table of Contents

1 Minimizing critical sections
2 RabbitFx: chunking
3 Different chunking
4 Experiments
5 Outlook
6 Some helicase benchmarks

This is a quick note on some thoughts & experiments on fasta parsing, alongside github:RagnarGrootKoerkamp/fasta-parsing-playground.

It’s a common complaint these days that Fasta parsing is slow. A common parser is Needletail (github), which builds on seq_io (github). Another recent one is paraseq (github).

Paraseq helps the user by providing an interface for parallel processing of reads, see eg this example. Unfortunately, this still has a bottleneck: while the users processing of reads is multi threaded, the parsing itself is still single threaded.

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!

High Throughput Bioinformatics

Sun, 06 Apr 2025 00:00:00 +0200

Table of Contents

1 Introduction
- 1.1 Overview
2 Optimizing Compute Bound Code: Random Minimizers
- 2.1 Avoiding Branch Misses
- 2.2 SIMD: Processing In Parallel
- 2.3 Instruction Level Parallelism
- 2.4 Input Format
3 Optimizing Memory Bound Code: Minimal Perfect Hashing
- 3.1 Using Less Memory
- 3.2 Reducing Memory Accesses
- 3.3 Interleaving Memory Accesses
- 3.4 Batching, Streaming, and Prefetching

This is Chapter 10 of my thesis (Groot Koerkamp 2025a), to introduce the last part on High Throughput Bioinformatics.

SimdSketch: a fast bucket sketch

Sun, 09 Mar 2025 00:00:00 +0100

Table of Contents

1 Jaccard similarity
2 Hash schemes
- 2.1 MinHash
- 2.2 $s$-mins sketch
- 2.3 Bottom-$s$ sketch
- 2.4 FracMinHash
- 2.5 Bucket sketch
- 2.6 Mod-bucket hash (new?)
- 2.7 Variants
3 Compressing sketches
- 3.1 $b$-bit hashing
  - 3.1.1 Accounting for collisions
- 3.2 HyperMinHash
4 Densification strategies
5 SimdSketch
6 Evaluation
- 6.1 Setup
  - 6.1.1 Tools
  - 6.1.2 Inputs
  - 6.1.3 Parameters
  - 6.1.4 Metrics
- 6.2 Raw results
- 6.3 Correlation
- 6.4 Comparison speed
- 6.5 Low-similarity data
7 Discussion
8 TODO / Future work

\[ \newcommand{\sketch}{\mathsf{sketch}} \]

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.

SimdMinimizers: Computing random minimizers, fast

Fri, 12 Jul 2024 00:00:00 +0200

Table of Contents

1 Introduction
- 1.1 Results
2 Random minimizers
3 Algorithms
4 Analysing what we have so far
5 Rolling our own hash
6 SIMD sliding window
- 6.1 Results
  - Human genome results
7 Extending into something useful
- 7.1 Collecting minimizer positions
- 7.2 Deduplicating the minimizer positions
- 7.3 Super-k-mers
- 7.4 Canonical k-mers
- 7.5 AntiLex hash
8 Conclusion
- 8.1 Future work

SimdMinimizers has been published as a paper: DOI, PDF:

A*PA2: Up to 19x faster exact global alignment

Sat, 23 Mar 2024 00:00:00 +0100

Table of Contents

Abstract
1 Introduction
- 1.1 Contributions
- 1.2 Previous work
  - 1.2.1 Needleman-Wunsch
  - 1.2.2 Graph algorithms
  - 1.2.3 Computational volumes
  - 1.2.4 Parallelism
  - 1.2.5 Tools
2 Preliminaries
3 Methods
- 3.1 Band-doubling
- 3.2 Blocks
- 3.3 Memory
- 3.4 SIMD
- 3.5 SIMD-friendly sequence profile
- 3.6 Traceback
- 3.7 A*
  - 3.7.1 Bulk-contours update
  - 3.7.2 Pre-pruning
- 3.8 Determining the rows to compute
  - 3.8.1 Sparse heuristic invocation
- 3.9 Incremental doubling
4 Results
- 4.1 Setup
- 4.2 Comparison with other aligners
- 4.3 Effects of methods
5 Discussion
Acknowledgements
Conflict of interest
6 Appendix
- 6.1 Bitpacking
- 6.2 Comparison with other aligners
- 6.3 Effects of methods

\begin{equation*} \newcommand{\g}{g^*} \newcommand{\h}{h^*} \newcommand{\f}{f^*} \newcommand{\cgap}{c_{\textrm{gap}}} \newcommand{\xor}{\ \mathrm{xor}\ } \newcommand{\and}{\ \mathrm{and}\ } \newcommand{\st}[2]{\langle #1, #2\rangle} \newcommand{\matches}{\mathcal M} \end{equation*}

One Billion Row Challenge

Wed, 03 Jan 2024 00:00:00 +0100

Table of Contents

External links
The problem
Initial solution: 105s
First flamegraph
Bytes instead of strings: 72s
Manual parsing: 61s
Inline hash keys: 50s
Faster hash function: 41s
A new flame graph
Perf it is
Something simple: allocating the right size: 41s
memchr for scanning: 47s
memchr crate: 29s
get_unchecked: 28s
Manual SIMD: 29s
Profiling
Revisiting the key function: 23s
PtrHash perfect hash function: 17s
Larger masks: 15s
Reduce pattern matching: 14s
Memory map: 12s
Parallelization: 2.0s
Branchless parsing: 1.7s
Purging all branches: 1.67s
Some more attempts
Faster perfect hashing: 1.55s
Bug time: Back up to 1.71s
Temperatures less than 100: 1.62s
Computing min as a max: 1.50
Intermezzo: Hyperthreading: 1.34s
Not parsing negative numbers: 1.48s
More efficient parsing: 1.44s
Fixing undefined behaviour: back to 1.56s
Lazily subtracting b'0': 1.52s
Min/max without parsing: 1.55s
Parsing using a single multiplication: doesn’t work
Parsing using a single multiplication does work after all! 1.48s
A side note: ASCII
Skip parsing using PDEP: 1.42s
- Improved
- A further note
Branchy min/max: 1.37s
No counting: 1.34s
Arbitrary long city names: 1.34
4 entries in parallel: 1.23s
Mmap per thread
Reordering some operations: 1.19s
Reordering more: 1.11s
Even more ILP: 1.05
Compliance 1, OK I’ll count: 1.06
TODO
Postscript

A youtube video on this post is here.

PtrHash: Notes on adapting PTHash in Rust

Thu, 21 Sep 2023 00:00:00 +0200

Table of Contents

Questions and remarks on PTHash paper
Ideas for improvement
Implementation log
PtrHash, part 2
- Phobic
  - TODO for PtrHash

\[ %\newcommand{\mm}{\,\%\,} \newcommand{\mm}{\bmod} \newcommand{\lxor}{\oplus} \newcommand{\K}{\mathcal K} \]

Diamond optimisation for diagonal transition

Mon, 01 Aug 2022 00:00:00 +0200

Table of Contents

Diamond transition or how technicalities can break concepts
- But let’s take a closer look
- Conclusion

Diamond transition or how technicalities can break concepts Link to heading

We assume the reader has some basic knowledge about pairwise alignment and in particular the WFA algorithm.

In this post we dive into a potential 2x speedup of WFA — one that turns out not to work.

Benchmark attention points

Thu, 28 Apr 2022 23:33:00 +0200

Benchmarking is harder than you think, even when taking into account this rule.

This post lists some lessons I learned while attempting to run benchmarks for A* pairwise aligner. I was doing this on a laptop, which likely has different characteristics from CPUs in a typical server rack. All the programs I run are single threaded.

Hardware Link to heading

Do not run while charging the laptop: Charging makes the battery hot and causes throttling. Run either on battery power or with a completely full battery to prevent this.
Disable hyperthreading: Completely disable hyperthreading in the BIOS. Multiple programs running on the same core may fight for resources.

CPU settings Link to heading

Pin CPU frequency: CPUs, especially laptops, have turboboost, (thermal) throttling, and powersave features. Make sure to pin the CPU core frequency low enough that it can be sustained for long times without throttling.
In my case, the performance governor can fix the CPU frequency. The base frequency of my CPU is 2.6GHz, so that’s where I pinned it.

28000x speedup with Numba.CUDA

Mon, 24 May 2021 00:00:00 +0200

Backlinks: r/CUDA, Numba discourse

Hpc on CuriousCoding

Sassy: fuzzy searching DNA sequences using SIMD

Route Planning using Customizable Contraction Hierarchies

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

Trying to understand DDR memory

Quotes from "The Evolution of Mathematical Software"

QuickHeap: the fastest priority queue

Chunking for Fasta Parsing

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

High Throughput Bioinformatics

SimdSketch: a fast bucket sketch

Static search trees: 40x faster than binary search

SimdMinimizers: Computing random minimizers, fast

A*PA2: Up to 19x faster exact global alignment

One Billion Row Challenge

PtrHash: Notes on adapting PTHash in Rust

Diamond optimisation for diagonal transition

Diamond transition or how technicalities can break concepts Link to heading

Benchmark attention points

Hardware Link to heading

CPU settings Link to heading

28000x speedup with Numba.CUDA

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