Marcin Panasiuk

Smells like template instantiation

2026-01-03T21:43:00+01:00

I've recently listened to a Wookash podcast with Andreas Fredriksson — Engine Lead at Insomniac. One line stuck with me: when working on his engine Andreas tries to keep each header file as small as possible so he can iterate on a single source file without much recompilation. One way he achieves that is by reducing the number of template definitions in headers.

Normally, templates have to live in headers, because the compiler needs to see the full definition at the point of use.

// t.h
template <typename T>
void my_template(T& t) {
 //...
}

So if you have two source files using the same template instantiated with the same type, the templated function will be duplicated.

// a.cc
#include "t.h"
my_template<A>(a);

// b.cc
#include "t.h"
my_template<A>(a);

If we compile this code:

g++ -c a.cc b.cc

And look for my_template definitions (T = text section):

nm -C a.o | grep -i my_template
0000000000000024 T void my_template(A&)
nm -C b.o | grep -i my_template
0000000000000024 T void my_template(A&)

We see that every translation unit that uses a template instantiates its own copy. More headers lead to more copies, which often make compile times skyrocket. Even if the linker later merges the duplicates, the milk is already spilled — the template was compiled multiple times.

Explicit templates

This is where explicit templates come in. Instead of letting every source instantiate templates implicitly, you can choose one place to do it explicitly:

// t.h
template <typename T>
void my_template(T& t);
extern template void my_template<A>(A&);
extern template void my_template<B>(B&);

// t.cc
#include "my_header.h"
template <typename T>
void my_template(T& t) {
 // implementation
}
// explicit instantiations
template void my_template<A>(A&);
template void my_template<B>(B&);

Now users of my_template<> don’t need the full definition. They just include the header, and the compiler links against the already-instantiated version.

If we were to compile this version:

g++ -c t.cc a.cc b.cc

And look for my_template definitions (T = text section) in t.cc

nm -C t.o | grep -i my_template
0000000000000000 T void my_template(A&)
0000000000000044 T void my_template(B&)

We would find definitions of explicitly specialized templates.

Now if we were to check other object files (U = Undefined reference):

nm -C a.o | grep -i my_template
                 U void my_template(A&)

nm -C b.o | grep -i my_template
                 U void my_template(B&)

We see that the symbol is used, but not defined there — it will be resolved by the linker.

Closing thoughts

So when to use it? For generic containers meant to store many different types, or for public API that need to stay flexible, standard templates are still the right tool. But for internal code, or for cases with a clearly fixed set of types (like vec3 or vec2), explicit template instantiation is very much worth considering.

The curious case of the conversion

2025-07-20T19:03:00+02:00

A few days ago a friend sent me this riddle:

#include 
void foo(float&&) { std::cout << "f"; }
void foo(int&&) { std::cout << "i"; }
template <typename... T>
void bar(T&&... v) {
 (foo(v), ...);
}
int main () {
 bar(1.0f, 2);
}

What will happen?

Let's walk through it carefully.

bar is a variadic function template taking variable number of parameters. When template parameters are deduced in this context, T&& is a forwarding reference (it can catch both lvalue and rvalue reference). However, inside the function body each parameter v is a named variable and therefore an lvalue, even if it was initialized from a rvalue.

(foo(v), ...) is a left-to-right fold-expression over the comma operator. It expands the pack and calls foo once for each v, evaluating the calls left-to-right. So inside bar we effectively do:

foo(v1); // where v1 = 1.f
foo(v2); // where v2 = 2

Wait, but there are no such functions defined! All we have are two functions foo taking rvalue references.

At this point I thought it could be a compiler error. There is no function foo taking lvalue reference. The only way the compiler could use defined functions is if it somehow created temporary variable inside the function calls...

And then it hit me. What about implicit conversions?

If the compiler converted 1.f into 1 (creating a temporary), then it would match the foo(int&&) signature and it would print "i". Then the compiler could repeat the same procedure for 2, converting it to float, and we would get "f". But would the compiler do it?

I was 50/50 sure. The compilation error would be more obvious choice, but the temporary conversion would make the riddle unexpectedly tricky.

It turned out that, indeed, the compiler does the conversions. The code compiles and prints:

if

Compilation error

So when would we get compilation error?

void foo(int&&) { std::cout << "i"; }
template <typename... T>
void bar(T&&... v) {
 (foo(v), ...);
}
int main () {
 bar(1);
}

If there were only one function foo matching parameter passed to bar.

g++ main.cc -std=c++17
main.cc:7:6: error: no matching function for call to 'foo'
    7 |     (foo(v), ...);
    |      ^~~
main.cc:11:5: note: in instantiation of function template specialization 'bar'
requested here
11 |     bar(1);
    |     ^
main.cc:3:6: note: candidate function not viable: expects an rvalue for 1st argument
    3 | void foo(int&&) { std::cout << "i"; }
    |      ^   ~~~~~
1 error generated.

Fixed version

How to fix the template? Use perfect forwarding:

template <typename... T>
void bar(T&&... v) {
 (foo(std::forward<T>(v)), ...);
}

Now v keeps its value category, overload resolution does what you expect, and the output is:

fi

What std::forward actually does

This is basically what it looks like (simplified):

template <typename T>
constexpr T&& forward(std::remove_reference_t<T>& t) noexcept {
 return static_cast<T&&>(t);
}

The entire trick is this cast:

static_cast<T&&>(t)

Conclusion

And how can you not love C++, ehh...

Perils of structured bindings

2025-03-17T19:43:00+01:00

C++17 introduced structured bindings:

auto [a, b] = func();

It looks innocent and convenient. You can think of it as:

auto __tmp = func();
// a and b are lvalue references to __tmp's members

There are two distinct steps here. First, func() produces a temporary. At this level, copy elision usually applies. Second, the bindings are initialized from that temporary. Here, things get less friendly.

Consider this example:

B func_ext() {
 auto [a, b] = func(); // RVO here
 return b; // no NRVO here!
}

Imagine b is a big structure. Returning b looks cheap. It isn’t. b is a named object. It is no longer the function’s return value. The compiler has to copy or move it.

Now compare this with a more traditional approach:

B func_ext() {
 A a;
 B b;
 func(&a, &b);
 return b; // NRVO here
}

Here, b is constructed directly as the return object. No detour. No extra copy.

Why does this happen?

When you call a function that returns a large object, the caller allocates space on its own stack and passes a hidden pointer to the callee:

func:
 sub rsp, sizeof(B) ; make space for return value
 lea rdi, [rsp] ; pass pointer to that space as hidden first argument
 call func_ext
 ; now [rsp] contains the B object

The callee receives this pointer and constructs the return value at that address:

func_ext:
 ; rdi = pointer to where caller wants the result
 ; construct B at address rdi
 ret

The "return slot" is just that space the caller allocated. The caller decides where it is. The callee must use it. When the compiler sees:

B func_ext() {
 A a;
 B b;
 func(&a, &b);
 return b;
}

It realizes b will become the return value. So instead of giving b its own space on func_ext's stack, it uses the pointer the caller provided. b is constructed directly where the caller wants it. When the function returns, there's nothing to copy — b and the return value are the same object at the same address.

Why subobjects break this?

B func_ext() {
 auto [a, b] = func();
 return b;
}

The hidden temporary looks like this in memory:

func_ext's stack frame:
    ┌─────────────────┐
    │      ...        │
    ├─────────────────┤ 0x7fff1000
    │       a         │   <- __tmp starts here
    ├─────────────────┤ 0x7fff1008
    │       b         │   <- b is at __tmp + 8
    ├─────────────────┤
    │      ...        │
    └─────────────────┘

Meanwhile, the caller said "put the return value at 0x7fff2050" (some address in the caller's frame). For NRVO to work, b would need to exist at 0x7fff2050. But b's address is 0x7fff1008 — it's determined by where __tmp lives plus a fixed offset.

Could the compiler fix this?

You might ask: why not place __tmp such that b lands at 0x7fff2050? That would put __tmp at 0x7fff2048 (so that __tmp + 8 = 0x7fff2050). But then a would occupy 0x7fff2048 — memory that's in the caller's stack frame, not ours. We'd be writing into memory we don't own. The caller only promised that 0x7fff2050 is valid for a b. It made no guarantees about the bytes before it.

A subobject's address is derived from its parent's address. The return slot's address is chosen by the caller. These are two independent constraints on where b must live, and you can't satisfy both. Hence, a copy:

...
mov rdx, QWORD PTR [rbp-16]
mov rax, QWORD PTR [rbp-152]
mov rsi, rdx
mov rdi, rax
call B::B(B const&) [complete object constructor]
...

Conclusion

Structured bindings are elegant. They also hide costs. If performance matters, don’t trust the surface syntax. Check the generated code. The disassembly rarely lies.

One arena to rule them all

2024-09-26T19:43:00+02:00

Memory management can be painful. We can use RAII and smart pointers, but sometimes it would be nice to have a garbage collector and not to worry about it at all. Especially if you needn't pay the price of periodic stalls. What if there were a way to make memory management much simpler?

Enter the Arena

An arena allocator owns one big chunk of memory and hands out parts of it linearly. An allocation is just the pointer arithmetic. There is no per-allocation free. When you are done with the arena, you reset it and all allocations disappear at once.

This pattern shows up everywhere: parsers, compilers, game frames, job systems, temporary scene data. If your objects naturally die together, an arena is often the simplest and fastest option.

So let's build one.

A simple arena

The arena itself only needs to know three things: where the memory starts, how big it is, and how much of it is already used.

struct ArenaAllocator {
 u8* base;
 size_t size;
 size_t offset;
};

void arena_init(ArenaAllocator* allocator, void* memory, size_t size) {
 allocator->base = (u8*)memory;
 allocator->size = size;
 allocator->offset = 0;
}

The core of the allocator is the allocation function itself:

void* arena_alloc(ArenaAllocator* allocator, size_t size, size_t alignment) {
 uintptr_t current = (uintptr_t)(allocator->base + allocator->offset);
 uintptr_t aligned = align_address_forward(current, alignment);
 size_t padding = aligned - current;
 if (allocator->offset + padding + size > allocator->size) {
 return nullptr;
 }
 allocator->offset += padding + size;
 return (void*)aligned;
}

This does three things. It aligns the current pointer, checks bounds, and bumps the offset. There is no metadata and no bookkeeping beyond that.

This helper rounds an address up to the next aligned boundary. Alignment must be power of 2 (usually 4 or 16)

uintptr_t align_address_forward(uintptr_t address, size_t alignment) {
 uintptr_t mask = alignment - 1;
 return (address + mask) & ~mask;
}

The function arena_alloc gives you raw memory. For convenience, let's wrap it with a typed helper:

template<typename T>
T* arena_push(ArenaAllocator* allocator, u32 count = 1) {
 return (T*) arena_alloc(allocator, sizeof(T) * count, alignof(T));
}

This works for trivial types and POD-like data. It does not call constructors or destructors. If you need that, you must explicitly use placement new.

MyType* obj = new (arena_push<MyType>(&allocator)) MyType(arg1, arg2);

Destruction is your responsibility, or you accept that destructors will never run and design your types accordingly. That trade-off is the whole point of an arena.

Freeing everything is trivial:

void arena_reset(ArenaAllocator* allocator) {
 allocator->offset = 0;
}

After this call, all previously returned pointers are invalid. The memory can be reused immediately.

Here is a complete example using mmap to get backing storage:

u8* memory = (u8*) mmap(nullptr, 1000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
ArenaAllocator allocator;
arena_init(&allocator, memory, 1000);
//...
MyData* data = arena_push<MyData>(&allocator);
int* arr = arena_push<int>(&allocator, 50);
//...
arena_reset(&allocator);
munmap(memory, 1000);

Conclusion

An arena allocator lets you reason about lifetimes as a whole. When lifetimes are grouped together — per frame, per request, per parse — an arena allocator makes this reality explicit instead of pretending every object is independent.

Used in the right place, it often leads to simpler code, fewer ownership concerns, and performance that is easy to reason about. It is not magic, and it does not pretend to be. If your data already lives and dies together, it is worth stopping and asking: could this be an arena?

It is just another tool in the shed — one that deserves to be taken off the wall more often.

Close Encounters of the LSH Kind

2024-05-11T21:45:00+02:00

Imagine you're building an antique shop, and need a signature verification tool. So you have a collection of signatures, each represented by a tuple of integers:

signatures = [
(1, 45, 2, 5, 10), # signature 0
(1, 17, 2, 5, 10), # similar to signature 0
(8, 99, 3, 7, 42), # different
(1, 45, 2, 5, 11), # similar to signature 0
# ...
# ...
# ...
]

Two signatures are similar if most of their positions match. You want to find all similar pairs.

The brute-force approach is O(N²) comparisons. For 10,000 items, that's ~50 million comparisons. For a million items, 500 billion. Can we do better?

Hash, baby, hash

Your first instinct might be: "Hash tables! I'll hash each signature and group identical ones."

matches = defaultdict(list)
for idx, signature in enumerate(signatures):
matches[signature].append(idx) # uses hash(signature) as a key

This finds exact duplicates instantly. But we don't want exact matches — we want similar matches. And regular hash functions are designed to do the opposite of what we need:

sig_a = (1, 2, 3, 4, 5)
sig_b = (1, 2, 3, 4, 6) # differs by just one position!
print(hash(sig_a)) # -5659871693760987716
print(hash(sig_b)) # 847769062341010709    <- completely different!

One tiny change, and the hash is unrecognisable. Similar signatures scatter across different buckets. We need a hash that keeps similar things together.

Divide and conquer

But what if, instead of hashing the whole signature, we would hash just parts of it?

signature = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)
# Split into 4 buckets of 3 values each
buckets = [
tuple(signature[0:3]), # (1, 2, 3)
tuple(signature[3:6]), # (4, 5, 6)
tuple(signature[6:9]), # (7, 8, 9)
tuple(signature[9:12]), # (10, 11, 12)
]

Now let's see what happens with two similar signatures:

sig_a = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)
sig_b = (1, 2, 3, 4, 5, 0, 7, 0, 9, 10, 11, 12)
#                     ^         ^  different positions
buckets_a = [(1,2,3), (4,5,6), (7,8,9), (10,11,12)]
buckets_b = [(1,2,3), (4,5,0), (7,0,9), (10,11,12)]
#            ^^^^^^^                    ^^^^^^^^^^^
#             match!                       match!

Even though the signatures differ in two positions, they have identical buckets at positions 0 and 3. If we hash each bucket separately, these signatures will collide in at least two hash tables.

That's the core of Locality-Sensitive Hashing: split signatures into buckets, hash each bucket into its own table, and call two items "candidates" if they collide in any bucket.

Locality-sensitive hashing

Let's build this step by step. First, splitting signatures into buckets:

def split_into_buckets(signature, num_buckets):
bucket_size = len(signature) // num_buckets
return [
tuple(signature[i * bucket_size : (i + 1) * bucket_size])
for i in range(num_buckets)
]
sig = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)
print(split_into_buckets(sig, 4))
# [(1, 2, 3), (4, 5, 6), (7, 8, 9), (10, 11, 12)]

Now we build one hash table per bucket. Each table maps a bucket's hash to the set of item IDs that have that bucket:

def build_index(signatures, num_buckets):
# one hash table per bucket
index = [defaultdict(set) for _ in range(num_buckets)]
for sig_idx, sig in enumerate(signatures):
buckets = split_into_buckets(sig, num_buckets)
for bucket_idx, bucket in enumerate(buckets):
index[bucket_idx][bucket].add(sig_idx)
return index

And to find candidates for a query signature, we check all buckets:

def find_candidates(index, query_sig, num_buckets):
candidates = set()
buckets = split_into_buckets(query_sig, num_buckets)
for bucket_idx, bucket in enumerate(buckets):
candidates.update(index[bucket_idx][bucket])
return candidates

Let's see it work:

signatures = [
(1, 2, 3, 4, 5, 6, 7, 8), # item 0
(1, 2, 3, 4, 5, 6, 0, 0), # item 1 - similar to 0
(9, 9, 9, 9, 9, 9, 9, 9), # item 2 - different
]
index = build_index(signatures, num_buckets=4)
candidates = find_candidates(index, signatures[0], num_buckets=4)
print(candidates) # {0, 1} - found the similar one!

But Why Does This Work?

Let's think about when two signatures collide in a bucket. They collide only if every position in that bucket matches. If a bucket has 3 positions, all 3 must match.

So, what's the probability of that happening?

Say two signatures have similarity s — meaning about a fraction s of their positions match. If we pick one position, there's probability s that it matches. For the whole bucket to match, we need all positions to match:

\begin{equation*} P_{bucket\,match} = 0.8^3 = 0.512 \end{equation*}

With 80% similarity and buckets of size 3, there's about a 51% chance any given bucket matches.

Now, for two items to become candidates, they need to match in at least one bucket. The easiest way to compute this is to flip it: what's the probability they match in no buckets?

s = 0.8 # similarity
r = 3 # rows per bucket
b = 4 # number of buckets

\begin{equation*} P_{bucket\,match} = s^r \end{equation*}

\begin{equation*} P_{no\,match} = (1 - P_{bucket\,match})^b \end{equation*}

\begin{equation*} P_{candidate} = 1 - P_{no\,match} = 1 - (1 - 0.512)^4 \approx 0.943 \end{equation*}

Two items with 80% similarity have a 94% chance of becoming candidates. Not bad!

The S-curve

Let's see how this probability changes with similarity:

def p_candidate(similarity, num_buckets, rows_per_bucket):
return 1 - (1 - similarity ** rows_per_bucket) ** num_buckets
# With 20 buckets of 5 rows each (100 total signature length)
b, r = 20, 5
for s in [0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9]:
p = p_candidate(s, b, r)
bar = "█" * int(p * 50)
print(f"sim={s}: {p:.3f} {bar}")

Output:

sim=0.2: 0.006
sim=0.3: 0.047 ██
sim=0.4: 0.186 █████████
sim=0.5: 0.470 ███████████████████████
sim=0.6: 0.802 ████████████████████████████████████████
sim=0.7: 0.975 ████████████████████████████████████████████████
sim=0.8: 1.000 █████████████████████████████████████████████████
sim=0.9: 1.000 ██████████████████████████████████████████████████

See the shape? There's a sharp transition around 0.5. Below it, pairs rarely become candidates. Above it, they almost always do. This is the S-curve — a soft filter that lets similar pairs through and blocks dissimilar ones.

Tuning the Filter

You can move the threshold by adjusting b and r:

threshold ~0.1 (b=50, r=2):
  sim=0.3: 0.991
  sim=0.5: 1.000
  sim=0.8: 1.000

threshold ~0.5 (b=20, r=5):
  sim=0.3: 0.047
  sim=0.5: 0.470
  sim=0.8: 1.000

threshold ~0.8 (b=10, r=10):
  sim=0.3: 0.000
  sim=0.5: 0.010
  sim=0.8: 0.679

The pattern:

More buckets (b) → lower threshold, catches more pairs (but more false positives)
More rows per bucket (r) → higher threshold, stricter filter (but might miss similar pairs)

The approximate threshold sits at:

\begin{equation*} {({\frac{1}{b}})}^\frac{1}{r} \end{equation*}

For b = 20, r = 5 that's about 0.55

Putting It Together

The full pipeline has three steps:

Build matches: Hash all signatures into bucketed tables
Find candidates: For each signature, collect items that share any bucket
Verify: Compute actual similarity for candidates, keep those above threshold

That last step is important. LSH gives you candidates, not guarantees. Some dissimilar pairs will slip through (false positives) — the verification catches them. Some similar pairs might be missed (false negatives) — tuning b and r controls this tradeoff.

def find_similar_pairs(signatures, num_buckets, threshold):
index = build_index(signatures, num_buckets)
candidate_pairs = set()
for i, sig in enumerate(signatures):
for j in find_candidates(index, sig, num_buckets):
if i < j: # avoid duplicates and self-matches
candidate_pairs.add((i, j))
# Verify candidates
results = []
for i, j in candidate_pairs:
# Count matching positions
matches = sum(a == b for a, b in zip(signatures[i], signatures[j]))
similarity = matches / len(signatures[i])
if similarity >= threshold:
results.append((i, j, similarity))
return results

How Much Faster?

Let's compare. With 10,000 items:

Brute force: 50 million comparisons
LSH: ~10,000 × 20 = 200,000 bucket lookups, plus verifying maybe a few thousand candidates

That's orders of magnitude less work. And it scales beautifully — the number of candidates depends on how many truly similar pairs exist, not on the total number of items.

Conclusion

LSH is one of those algorithms that feels like cheating. You're trading a small chance of missing similar pairs for a massive speedup. In most applications, that's exactly the right trade.

The next time you see "similar items" appear instantly on a site with millions of products, there's a good chance LSH is working behind the scenes — a hash function that learned to keep similar things together.

Close Encounters of the MinHash Kind

2023-07-14T21:33:00+02:00

Imagine you're building a meme recommendation system. Users upload memes, and your task is to find all similar ones quickly. A meme is described by a set of features, e.g., ["sun", "dog", "car"]. Memes are considered similar if they share most of their features:

meme_1 = ["floor", "sun", "dog", "car"] # similar to meme_2
meme_2 = ["sun", "ball", "dog", "car"] # similar to meme_1
meme_3 = ["tree", "grass", "dog"] # different from both

How would you find all similar memes?

A straightforward approach would be to directly compare every meme with every other meme. However, for N memes, this results in O(N²) comparisons — clearly not efficient. We can do better!

The Intuition

Let's think about it. If two memes share most of their features, then picking a random feature from the combined set has a high chance of being present in both. If we repeat this process multiple times, similar memes will match more frequently than different ones.

This gives us the core insight, but random sampling has a practical drawback: we'd need to coordinate and store our random choices to ensure consistency across comparisons. What if we could achieve the same effect deterministically?

From Random Sampling to Hashing

What if, instead of picking features at random, we defined a consistent rule for selecting one feature from each meme? Here's the trick: use a hash function.

A hash function maps each feature to a number, giving us an implicit ordering. For each meme, we hash all its features and keep only the minimum hash value. This is called the min-hash of that meme.

def min_hash(features, hash_func):
return min(hash_func(f) for f in features)

Why does this help? If two memes are similar (they share most of their features), they're likely to agree on which feature has the minimum hash — because they're mostly hashing the same set!

More precisely, the probability that two memes have the same min-hash equals their Jaccard similarity (the size of their intersection divided by the size of their union).

A Concrete Example

Let's see this in action. Suppose our hash function produces these values:

# hash("sun")=3, hash("dog")=7, hash("car")=12,
# hash("floor")=25, hash("ball")=9, hash("tree")=1, hash("grass")=15
meme_1 = ["floor", "sun", "dog", "car"] # min_hash = 3  (from "sun")
meme_2 = ["sun", "ball", "dog", "car"] # min_hash = 3  (from "sun") ✓ match!
meme_3 = ["tree", "grass", "dog"] # min_hash = 1  (from "tree")

With this particular hash function, meme_1 and meme_2 have the same min-hash, while meme_3 differs. But one hash function isn't enough — we might get unlucky. The solution? Use many hash functions.

Building a Signature

If we repeat this process using k different hash functions, we get a signature for each meme: a vector of k min-hash values.

def compute_signature(features, hash_functions):
return [min_hash(features, h) for h in hash_functions]
# Using 100 hash functions, each meme gets a signature of 100 integers
sig_1 = compute_signature(meme_1, hash_functions) # [3, 42, 7, 91, ...]
sig_2 = compute_signature(meme_2, hash_functions) # [3, 42, 7, 18, ...]
sig_3 = compute_signature(meme_3, hash_functions) # [1, 55, 2, 36, ...]

The fraction of positions where two signatures match estimates their Jaccard similarity. In the example above, sig_1 and sig_2 might match in 75 out of 100 positions, while sig_1 and sig_3 might match in only 10.

Now, instead of comparing full feature sets, we compare compact integer vectors — much faster!

Conclusion

MinHash turns an O(N²) comparison problem into something much more manageable. Instead of comparing every meme to every other meme, we compute a small signature for each meme in O(N × k) time, where k is the number of hash functions.

Memes with similar signatures are likely to be similar — and we can find them efficiently using techniques like Locality-Sensitive Hashing (LSH), which buckets signatures so that similar items land in the same bucket with high probability.

This family of techniques powers similarity search at scale: near-duplicate detection, recommendation systems, plagiarism detection, and more. Not bad for a bit of hashing!

Sweet Variant o’ Mine

2023-02-11T16:48:00+01:00

Rust’s enums (or should I say tagged unions) are a powerful tool for representing data that can take multiple forms, each with its own type and constructor.

For example, consider a Message that encapsulates different message types:

enum Message {
 Quit,
 Move { x: i32, y: i32 },
 Write(String),
 ChangeColor(i32, i32, i32),
}

Here, each variant can hold distinct data types, from no data (Quit) to complex structures (Move). Pattern matching with match ensures exhaustive handling of all cases at compile time, blending flexibility with safety:

fn handle_message(msg: Message) {
 match msg {
 Message::Quit => println!("Quit"),
 Message::Move { x, y } => println!("Move to ({}, {})", x, y),
 // ... other variants handled explicitly
 }
}

In C++, std::variant (since C++17) can mimic this behavior — but not without some boilerplate. First, define individual types for each variant:

struct Quit {};
struct Move { int x, y; };
struct Write { std::string s; };
struct ChangeColor { int r, g, b; };
using Message = std::variant<Quit, Move, Write, ChangeColor>;

Handling the variant requires a visitor - often using std::visit and a helper overloaded to combine lambdas:

// helper type for the visitor
template<class... Ts>
struct overloaded : Ts... { using Ts::operator()...; };
// explicit deduction guide (not needed as of C++20)
template<class... Ts>
overloaded(Ts...) -> overloaded<Ts...>;
void handle_message(const Message& msg) {
 std::visit(overloaded{
 [](const Quit&) { printf("Quit\n"); },
 [](const Move& m) { printf("Move to (%d, %d)\n", m.x, m.y); },
 // ... other cases
 }, msg);
}

Let’s be real: C++’s variant won’t match Rust enums for elegance. But that’s C++ in a nutshell - it hands you the tools to solve nearly any problem, even if the solution is a little rough around the edges. Yes, defining structs and writing visitors with overloaded lambdas is boilerplate-heavy, but it’s there if you ever need it. Just don't overuse it.

Trust the Source, Luke

2022-08-01T20:30:00+02:00

It is a common belief that the only documentation a programmer should rely on is the source code. Some experienced engineers argue that one should only trust the disassembly. However, I'd like to present a case where neither of these beliefs holds true.

Consider this kernel code:

int x;
void kernel_func(int index) {
 if (index < public_bounds) {
 x = x ^ detector[secret[index] * SOME_BIG_NUMBER];
 }
}

void kernel_func(int) PROC
 push ebp
 mov ebp, esp
 mov eax, DWORD PTR _index$[ebp]
 cmp eax, DWORD PTR int public_bounds
 jge SHORT $LN1@kernel_fun
 mov ecx, DWORD PTR _index$[ebp]
 mov edx, DWORD PTR int * secret[ecx*4]
 imul edx, DWORD PTR int SOME_BIG_NUMBER
 mov eax, DWORD PTR int x
 xor eax, DWORD PTR int * detector[edx*4]
 mov DWORD PTR int x, eax
$LN1@kernel_fun:
 pop ebp
 ret 0

Could we obtain the value of the secret[index] for indices outside of public_bounds, if we only have access to index, detector[] and the value of SOME_BIG_NUMBER? According to the source code and disassembly we should not, right?

Right?

Welcome to hardware land! The CPU hates idleness. If there is a cache miss in the branch condition index < public_bounds, which would make CPU stall for a while, CPU can speculatively execute x = x ^ detector[secret[index] * ...]. If the condition, fetched from memory, turns out to be false, the CPU simply doesn't commit the speculative result. So, what's the issue? The problem arises because the CPU can fetch detector[secret[index] * ...] into the cache, even if the branch condition is not met!

In the user process, we could have evicted the entire cache, executed kernel_func making CPU do branch prediction (by running it with a valid index a few times beforehand), and then executed:

auto start = __rdtsc(); // high-precision timer
auto tmp = detector['A' * SOME_BIG_NUMBER];
auto end = __rdtsc();
auto diff = end - start;

In this manner, we could have determined if secret[index] was 'A' simply by measuring the time difference (a small time indicates it was fetched into the cache by speculative execution). We could repeat the entire process for 'B', 'C', 'D', etc., and voilà!

This vulnerability, called Spectre, has been described in more detail in "Reading privileged memory with a side-channel" by Jann Horn.

Be careful where you place your trust.

Need for speed: C++ unity builds

2022-05-16T19:51:00+02:00

As I type these words, I'm staring at the LLVM compilation screen. It has been running for an hour. What a waste of energy. I really hate long compilation times.

That's why I started using unity builds. A unity build consolidates all code into a single translation unit:

#include "file_1.cc"
#include "file_2.cc"
#include "file_3.cc"
#include "file_4.cc"
#include "file_5.cc"

How much time can I save by organizing code in this manner? I wrote a simple test where I generated 10,000 files:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
class MyTestClazzX {
public:
 void func(const std::string& str) {
 std::cout << "Hello from class MyTestClazzX: " + str << std::endl;
 }
};

Then I performed different compilations using normal and unity builds. Here are the results:

➜ unity-builds-cmp git:(main) ✗ python test_unity_build.py 10000
Cleaning src/ directory
Generating 10000 files...
Compiling unity build... [g++]
 DONE. The process took 20.84 seconds
Compiling unity build using... [clang++]
 DONE. The process took 10.60 seconds
Compiling normal build using 12 cores... [clang++]
 DONE. The process took 916.86 seconds

The single-threaded unity build was about 90 times faster than the normal one, even though the normal build was utilizing multiple cores. Of course, the exact results are artificial and depend very much on the files you are compiling, but the sheer difference is astonishing.

I use unity builds for my private projects, which usually do not have more than 100 files. So, here are the results for 100:

➜ unity-builds-cmp git:(main) ✗ python test_unity_build.py 100
Cleaning src/ directory
Generating 100 files...
Compiling unity build... [g++]
 DONE. The process took 0.64 seconds
Compiling unity build using... [clang++]
 DONE. The process took 0.58 seconds
Compiling normal build using 12 cores... [clang++]
 DONE. The process took 7.48 seconds

About 13 times faster. This is noticeable and definitely worthwhile for me. It compiles under one second without using precompiled headers, incremental builds or pimpl. A full rebuild. Each time. In under one second.

So, what about cons? Certainly, putting everything into a single translation unit can result in a big mess:

Static clash

Symbols with identical names and internal linkage can result in lots of redefinition errors.
Macro mayhem

Preprocessor directives now operate in a global battlefield. That innocuous #define MAX_SIZE 1024 in a source header? It might silently override a same-named constant in an unrelated subsystem.
No unnamed namespaces

Technically, you can use unnamed namespace, but everything will be put inside single one. You want to use a helper function that should only be visible in this small module? Too bad. It will be visible globally.

Ambiguous overloads

The C++ overload resolution rules are quite complex and when everything is in one translation unit, it can lead to some surprises, e.g.:
// file_1.cc
struct Foo {
 Foo(int var) {}
};
void func(Foo f) {}
// file_2.cc
struct Bar {
 Bar(int var) {}
};
void func(Bar b) {}
// main.cc
#include "file_1.cc"
#include "file_2.cc"
func(42);
Results in error: call to 'func' is ambiguous.

External dependencies

Due to leaky C++ nature, you can design all of your code in unity-friendly manner and it might still explode when you include some external library.

How do I deal with it?

Well, I am using it for my own projects written from scratch. It is easier to write code for unity builds from the beginning than to transform big, complex codebase into it. My ruleset:

I organize my codebase into modules with their own namespaces and try not to break dependency rules
I rarely use macros. And if I do, I prefix them with a module-specific identifier.
As far as external libraries are concerned, I usually put them into separate DLLs and hope headers are written properly. Alternatively, for a small project, you might try including it directly. You never know.

Interview with the Programmer

2022-01-13T17:04:00+01:00

Hiring a good programmer is hard. Not “come up with clever LeetCode puzzles” hard — actually figuring out how someone thinks hard.

Over the years I’ve seen a few interview styles that really stuck with me. These aren’t about trick questions or whiteboard gymnastics. They’re about getting a glimpse into how someone approaches real problems. Here are three of my favourites:

"Tell me about your project, and I'll tell you who you are..."

In this simulated interview, Shawn McGrath walks Casey Muratori through his custom anti-aliasing implementation. Casey plays the role of a genuinely curious engineer and just keeps asking why and how.

What I like about this approach is how naturally it exposes depth. You can tell very quickly whether someone really understands the trade-offs they made, or if they just followed a tutorial and hoped for the best. Unlike toy algorithm problems, talking through a real project shows how a programmer thinks when things get messy—which is, let’s be honest, most of the job.

"Found this bug. What could have caused it?"

Hussein Nasser talks about his favorite interview question, and it’s a great one. He starts by sketching out a system - database, backend, reverse proxy, load balancer, frontend—and then drops a concrete problem on the table. For example: the UI freezes for about a minute after clicking a button.

From there, the candidate is free to explore. How would you debug this? Where would you start? What do you suspect?

What’s clever here is that it’s completely open-ended. People naturally gravitate toward the parts of the system they understand best, and that tells you a lot. According to Hussein, he’s never gotten the same answer twice—and that tracks with my experience too.

"Here's the source code. Add a feature..."

In this interview write-up, the task is to add support for an atomic mult command to Memcached.

I love this style because it’s unapologetically practical. You’re dropped into an unfamiliar codebase and asked to make a real change. No puzzles, no brainteasers - just: can you read code, reason about it, and ship something without panicking?

This kind of exercise tends to surface pragmatic programmers - the ones who aren’t afraid to get their hands dirty, ask the right questions, and make progress even when everything isn’t perfectly documented.

Crazy Little Thing Called Float

2021-11-20T11:28:00+01:00

What's wrong with this C++ code?

int main() {
 float f = 16777217.f;
 while (f < 16777218.f) {
 f += 1.f;
 }
 printf("%f\n", f);
}

It will run forever.

It's pretty common knowledge that the best way to go broke is to use floats for storing money. Indeed, not all rational numbers can be represented as floating-point numbers:

printf("%1.10f\n", 0.7f); // 0.6999999881

Floats use a sign, exponent, and significand (mantissa) to represent real numbers. These gaps exist because floating-point numbers have fixed precision but variable scale:

\begin{equation*} value = (-1)^{sign} \cdot 2^{exponent - 127} \cdot (1 + fraction) \end{equation*}

A 32-bit float has:

1 bit for the sign
8 bits for the exponent
23 bits for the significand (with an implicit leading bit, giving 24 bits of precision)

Because the fraction has only 23 explicit bits, it can only store 24-bit precision at any given scale. This means that numbers are spaced uniformly within a power of two, but the step size doubles every time the exponent increases. Therefore, floating-point numbers not only have gaps, but the distribution of these gaps is also not uniform. The farther away from 0.0, the larger empty spaces we can expect.

Let's look at the numbers from the first code sample:

printf("%20.16f\n", 16777217.f); // 16777216.0000000000000000
printf("%20.16f\n", 16777218.f); // 16777218.0000000000000000

Between 16,777,216 and 16,777,218, there is a pretty large gap. If you kept tracking your dollars as floats around 16 million, there would be gaps as big as $2. At around 140,000,000 we can find gaps of size $16. At around 1,000,000,000 of size $64.

The gap size depends on the exponent. Every time the number doubles, the gap size doubles:

for numbers in the range [1, 2), the gap is 2^-23 = 0.00000011920928955078125
at 8,388,608, the gap is 1
at 16,777,216, the gap is 2
at 134,217,728, the gap is 16
at 1,073,741,824, the gap is 64.

The pattern follows:

\begin{equation*} gap = 2^{exponent - 23} \end{equation*}

Value Range	Exponent e	Gap size
[1, 2)	0	2^-23
[2, 4)	1	2^-22
[4, 8)	2	2^-21
[8,388,608, 16,777,216)	23	1
[16,777,216, 33,554,432)	24	2
[134,217,728, 268,435,456)	27	16
[1,073,741,824, 2,147,483,648)	30	64

You can play with floating-point representation using this nice tool.

First post

2021-09-13T11:43:00+02:00

fn main() {
 println!("Hello world!");
}

This is my first post. Inspired by Jakub Stasiak's blog (which I highly recommend checking out), I've finally decided to start my blogging adventure. To do so, I am using Pelican, and so far it's working wonderfully — I'm glad I resisted the temptation to roll my own solution.

For the theme, I’m using a modified version of Jakub's theme, which I’ve been tweaking during late-night hours. After some experimentation, I settled on a darker theme that feels easy on the eyes.