DEV Community: David Álvarez Rosa

Self-Hosting Behind CGNAT

David Álvarez Rosa — Tue, 22 Sep 2026 16:19:18 +0000

There is nothing more satisfying than owning, end to end, the software and the hardware you use without relying on abusive cloud corporations. Internet is us, not them. Break free from censorship. Learn how to self-host at home, and be truly libre.

In the past, self-hosting was easier. You just had to open a port on your router and forward it to any machine at home.¹ Nowadays, the shortage of IPv4 addresses means routers share the same IP across your neighborhood. Requests are routed using carrier-grade NAT (CGNAT), a second-layer NAT inside the carrier's network, where your router's address is private and translated by the carrier on the way out. The public address is the carrier's, so port forwarding no longer works.

Topology

My services run on a mid-range machine in my mother's basement in northern Spain, and are exposed to the Internet through a cheap VPS bridge in a French data center.

  +-------------------------------------+
  |           public Internet           |
  +-------------------------------------+
        ^                       ^
        | inbound               |
        v                       |
  +------------+                |
  |   bridge   |                | egress
  +------------+                |
        ^^                      |
        || WireGuard            |
        vv                      |
  +-------------------------------------+
  |               homelab               |
  +-------------------------------------+

Topology diagram. The homelab is exposed to the Internet through a WireGuard tunnel to a VPS bridge.

A bidirectional WireGuard tunnel² forwards all packets in all ports from the bridge to the homelab box, and vice versa. The beauty of this is that the tunnel is initiated by the homelab, so you don't need a static dedicated IP at home.³ The penalty of the bridge is 39 ms of RTT.

Tunnel configuration

Bridge's wg0.conf.⁴

[Interface]
Address = 10.0.0.1/24
PrivateKey = <bridge-private-key>
ListenPort = 51820
PostUp = ...
PostDown = ...

[Peer]
PublicKey = <homelab-public-key>
AllowedIPs = 10.0.0.2/32

PostUp sets up NAT and forwarding rules at the kernel level.⁵ The first two exclude ports 2222 for SSH, and 51820 for the VPN tunnel itself. The last three forward all traffic in all ports to the homelab. The destination is rewritten but not the source, so the homelab sees the real client IPs.

iptables -t nat -A PREROUTING -i ens3 -p udp --dport 51820 -j RETURN
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 2222 -j RETURN
iptables -t nat -A PREROUTING -i ens3 -j DNAT --to-destination 10.0.0.2
iptables -A FORWARD -i wg0 -o ens3 -s 10.0.0.2 -j ACCEPT
iptables -A FORWARD -i ens3 -o wg0 -d 10.0.0.2 -j ACCEPT

Homelab's wg0.conf.⁶

[Interface]
Address = 10.0.0.2/24
PrivateKey = <homelab-private-key>
Table = off
PostUp = ip route add default dev wg0 table 200
PostUp = ip rule add from 10.0.0.2 table 200
PostDown = ...

[Peer]
PublicKey = <bridge-public-key>
Endpoint = 213.32.19.229:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Replies from the homelab have to go back down the tunnel. That is what the config is for, sending those replies through the bridge, while leaving the homelab's own traffic on the home router.⁷

Resilience

Three pieces can fail.

Homelab. A cronjob in the homelab checks whether SSH is still working and, if it is not, reboots the box.
Bridge. In case it fails, I recommend a backup entry point like a Cloudflare tunnel or Tailscale directly to the homelab.
Tunnel. A short drop re-handshakes on its own. A longer one is covered by the two cases above.

Own your services. Be libre and have fun!

A dynamic DNS service kept your domain pointing at the right public IP whenever your ISP rotated it. ↩
WireGuard is a fast, modern and secure VPN tunnel that lives inside the Linux kernel. ↩
Buying a static IP from your ISP is a valid alternative, at around 20 euros a month in Spain. ↩
See First Steps on a New Server for how I set up a fresh machine. ↩
And PostDown removes them when the tunnel goes down. ↩
Its full configuration lives in my homelab repository. ↩
From then on, SSH to ssh.alvarezrosa.com at port 22 lands on the homelab, and port 2222 on the bridge. ↩

Optimizing a Spin-Lock

David Álvarez Rosa — Wed, 09 Sep 2026 17:16:31 +0000

A spin-lock is a lock that never sleeps. Instead of yielding to the scheduler, the thread stays on the CPU and spins. No syscalls. No context switches. In this post, we'll build a version, step by step, that is 5.7x faster while drawing 5.4x less energy.

Benchmark

Threads increment a shared counter under the lock.¹

template <typename Lockable>
auto BM_SpinLock(benchmark::State& state) -> void {
  alignas(std::hardware_destructive_interference_size) static auto lockable =
      Lockable{};
  alignas(std::hardware_destructive_interference_size) static auto counter =
      std::uint64_t{};

  pinThread(state.thread_index());
  for (auto _ : state) {
    lockable.lock();
    ++counter;
    lockable.unlock();
  }
  benchmark::DoNotOptimize(counter);
}

The lock and the counter get a cache line each. Threads are pinned.

A naive spin-lock

An atomic bool and an exchange loop.²

class SpinLockV1 {
  std::atomic_bool locked_{false};

public:
  auto lock() noexcept -> void { while (locked_.exchange(true)); }
  auto unlock() noexcept -> void { locked_.store(false); }
};

Uncontended it takes 3.14 ns. Two threads take 61.5 ns, twenty times as long. Four take 246 ns.

$ ./benchmark --benchmark_filter='V1>'
BM_SpinLock<SpinLockV1>/real_time/threads:1      3.14 ns
BM_SpinLock<SpinLockV1>/real_time/threads:2      61.5 ns
BM_SpinLock<SpinLockV1>/real_time/threads:4       246 ns

A core must own the line exclusively to write it, so waiters take it from each other. L1-d misses go from 1.27% at one thread to 61.73% at four, and one branch in eight is mispredicted.³

$ perf stat -d ./benchmark --benchmark_filter='V1>.*threads:1'
1,638,619,370      instructions           # 0.51  insn per cycle
      244,253      branch-misses          # 0.11% of all branches
       75,519      L1-dcache-load-misses  # 1.27% of all L1-dcache accesses

$ perf stat -d ./benchmark --benchmark_filter='V1>.*threads:4'
1,231,495,723      instructions           # 0.02  insn per cycle
   33,824,516      branch-misses          # 12.52% of all branches
  208,756,315      L1-dcache-load-misses  # 61.73% of all L1-dcache accesses

Spinning costs energy.⁴ At four threads it draws 64.92 J.⁵

$ perf stat -a -e power/energy-pkg/ ./benchmark --benchmark_filter='V1>.*threads:4'
          64.92 Joules power/energy-pkg/

Memory ordering

The default is seq_cst, stronger than a lock needs. It only has to acquire on the way in and release on the way out.

class SpinLockV2 {
  std::atomic_bool locked_{false};

public:
  auto lock() noexcept -> void {
    while (locked_.exchange(true, std::memory_order_acquire));
  }
  auto unlock() noexcept -> void {
    locked_.store(false, std::memory_order_release);
  }
};

On x86 lock is unchanged.

SpinLockV2::lock():
        mov     al, 1
        xchg    byte ptr [rdi], al  // Locked exchange, both orderings
        test    al, 1
        jne     .LBB0_1
        ret

The difference is in unlock. The default ordering adds a second locked read-modify-write, on top of the one in lock.

SpinLockV1::unlock():
        xor     eax, eax
        xchg    byte ptr [rdi], al  // Locked read-modify-write
        ret

With memory_order_release, unlock is a plain store.

SpinLockV2::unlock():
        mov     byte ptr [rdi], 0   // Plain store
        ret

One atomic instead of two. 3.14 ns to 1.57 ns uncontended, 246 ns to 131 ns at four threads.

$ ./benchmark --benchmark_filter='V2>'
BM_SpinLock<SpinLockV2>/real_time/threads:1      1.57 ns
BM_SpinLock<SpinLockV2>/real_time/threads:2      32.5 ns
BM_SpinLock<SpinLockV2>/real_time/threads:4       131 ns

Miss rates fall too. L1-d 61.73% to 21.16%, branches 12.52% to 7.43%. Energy drops to 34.45 J.

$ perf stat -d ./benchmark --benchmark_filter='V2>.*threads:4'
773,887,322      instructions           # 0.03  insn per cycle
 12,348,239      branch-misses          # 7.43% of all branches
 99,804,390      L1-dcache-load-misses  # 21.16% of all L1-dcache accesses

The exchange writes the line even when it fails. Waiters must stop writing.

Test and test-and-set

Exchange once, then wait on a read-only load. The _mm_pause instruction marks the loop as a spin-wait, so the core idles.⁶

class SpinLockV3 {
  std::atomic_bool locked_{false};

public:
  auto lock() noexcept -> void {
    while (locked_.exchange(true, std::memory_order_acquire)) {
      while (locked_.load(std::memory_order_relaxed)) {  // Read-only spin
        _mm_pause();                                     // Backoff
      }
    }
  }
  auto unlock() noexcept -> void {
    locked_.store(false, std::memory_order_release);
  }
};

Two threads drop by a third, 32.5 ns to 21.3 ns. Four threads gain 8%, 131 ns to 120 ns.

$ ./benchmark --benchmark_filter='V3>'
BM_SpinLock<SpinLockV3>/real_time/threads:1      1.58 ns
BM_SpinLock<SpinLockV3>/real_time/threads:2      21.3 ns
BM_SpinLock<SpinLockV3>/real_time/threads:4       120 ns

L1-d misses fall from 21.16% to 17.31%, branches from 7.43% to 3.72%. A read-only spin is predictable.

$ perf stat -d ./benchmark --benchmark_filter='V3>.*threads:4'
1,290,214,448      instructions           # 0.05  insn per cycle
   12,089,906      branch-misses          # 3.72% of all branches
   83,836,255      L1-dcache-load-misses  # 17.31% of all L1-dcache accesses

Energy falls 10%, from 34.45 J to 30.97 J.

$ perf stat -a -e power/energy-pkg/ ./benchmark --benchmark_filter='V3>.*threads:4'
          30.97 Joules power/energy-pkg/

Every waiter pauses for the same length of time, so they all wake together.

Exponential backoff

Intel documents the fix. Wait longer each round, doubling up to a cap.⁷

class SpinLockV4 {
  std::atomic_bool locked_{false};

public:
  auto lock() noexcept -> void {
    auto backoff = 1;
    while (locked_.exchange(true, std::memory_order_acquire)) {
      do {
        for (auto i = 0; i < backoff; ++i) _mm_pause();   // Backoff
        backoff = backoff < 64 ? backoff << 1 : 64;       // Exp. growth
      } while (locked_.load(std::memory_order_relaxed));  // Read-only spin
    }
  }
  auto unlock() noexcept -> void {
    locked_.store(false, std::memory_order_release);
  }
};

Waiters back off by different amounts and stop waking together. Four threads drop from 120 ns to 43.0 ns.

$ ./benchmark --benchmark_filter='V4>'
BM_SpinLock<SpinLockV4>/real_time/threads:1      1.58 ns
BM_SpinLock<SpinLockV4>/real_time/threads:2      18.3 ns
BM_SpinLock<SpinLockV4>/real_time/threads:4      43.0 ns

L1-d misses fall from 17.31% to 12.88%.

$ perf stat -d ./benchmark --benchmark_filter='V4>.*threads:4'
600,071,010      instructions           # 0.07  insn per cycle
  8,296,063      branch-misses          # 6.17% of all branches
 33,717,087      L1-dcache-load-misses  # 12.88% of all L1-dcache accesses

Energy falls to 11.92 J, 5.4x less than the naive version.

$ perf stat -a -e power/energy-pkg/ ./benchmark --benchmark_filter='V4>.*threads:4'
          11.92 Joules power/energy-pkg/

Summary

Reproduce it with the benchmark.

Version	1 thread	2 threads	4 threads	Notes
V1	3.14 ns	61.5 ns	246 ns / 64.92 J	Naive
V2	1.57 ns	32.5 ns	131 ns / 34.45 J	Memory ordering
V3	1.58 ns	21.3 ns	120 ns / 30.97 J	Test and test-and-set
V4	1.58 ns	18.3 ns	43.0 ns / 11.92 J	Exponential backoff

In most code, std::mutex is still the right default. Consider a spin-lock when the threads are pinned to dedicated cores, and only after measuring.⁸

Run on a box tuned for benchmarking. Built with clang. All optimizations enabled. ↩
exchange atomically writes true and returns the previous value. false means the lock was free and is now ours. true means someone else holds it, so we retry. ↩
Whether the exchange succeeds is decided by the other cores, so the branch predictor has nothing to learn. ↩
High-frequency trading shops care about it. Exchange colocation services charge for power, and NYSE caps at 32 kW. ↩
Reading the RAPL counters requires system-wide mode (-a) and root, so the figure covers the whole package, idle cores included. ↩
The load can be relaxed. What orders the critical section is the exchange that succeeds, not the reads that fail. ↩
Example 2-10, Contended Locks with Increasing Back-off, in the Intel Optimization Reference Manual (PDF, 248966-050US). ↩
With one writer and many readers, consider a seqlock instead. ↩

One Hundred Thousand Reads

David Álvarez Rosa — Sat, 18 Jul 2026 10:53:50 +0000

This site just passed one hundred thousand reads. It started as a public notebook that almost no one read. The plan hasn't changed: one post a month, no quick takes, only deep dives into things I care about. If you have read even one, thank you. That number is you.

Visitors stay five and a half minutes on average. Reddit and Hacker News send almost nine in ten of them; every search engine put together sends fewer than one in twenty.

The traffic comes in spikes: a post hits a front page, pulls a few thousand reads in a day, then goes quiet. The three most-read posts owe over 41,000 reads to a few such days.¹

Thank you, again, for reading.

Optimizing a Lock-Free Ring Buffer leads with 17,169 reads, followed by the Fundamental Theorem of Calculus (12,575) and Devirtualization and Static Polymorphism (11,961). ↩

Tuning a Server for Benchmarking

David Álvarez Rosa — Fri, 26 Jun 2026 16:50:06 +0000

Optimizing code starts with measuring it, and a measurement is only useful if it is repeatable: a 2% improvement is invisible under 5% of noise. Yet on an untuned machine the same binary can easily run several percent faster or slower between runs. In this post we take a tiny benchmark and tune the machine step by step, re-measuring after every change, until runs become deterministic.

Continue reading---Tuning a Server for Benchmarking

Self-Hosting on the Dark Web

David Álvarez Rosa — Mon, 01 Jun 2026 10:56:24 +0000

This site is now reachable over Tor as a hidden service, at a .onion address that resolves only inside the Tor network.¹ Tor relays and encrypts your traffic as it passes through thousands of volunteer-run servers, so that no single party can link who you are to what you are doing; a hidden service extends that anonymity to the server itself.

It's built by the nonprofit Tor Project, which advances human rights and freedoms through free software and open networks, so that anyone can use the internet free from tracking, surveillance, and censorship. The network only works because people use it, so consider supporting them or running a relay---your contribution helps millions stay safe and private online every day.

The hidden service

Install Tor and point a hidden service at a local port. Edit /etc/tor/torrc

HiddenServiceDir /var/lib/tor/blog/
HiddenServicePort 80 127.0.0.1:8080

The directory must be a dedicated, Tor-owned path---not your web root.² Restart Tor and read the address it generates

$ sudo systemctl restart tor@default
$ sudo cat /var/lib/tor/blog/hostname
dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion

Serving the site

Tor forwards the onion's port 80 to 127.0.0.1:8080, so the web server just needs to listen there. Add an nginx server block for it---no TLS, no HTTP/2, no QUIC, since Tor speaks plain TCP and provides its own encryption.

server {
  listen 127.0.0.1:8080;
  server_name dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion;

  root /srv/tor.david.alvarezrosa.com;
  index index.html;
  error_page 404 /404/index.html;

  location / {
    try_files $uri $uri/ =404;
  }
}

Reload nginx and the site is live on Tor.

Building for the onion

A static site bakes its base URL into absolute links, so a clearnet build would point visitors back to the clearnet domain even when served over Tor. The fix is to build a second copy with the onion as its base URL

$ hugo --minify --baseURL="http://dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion/"

The deploy pipeline does this automatically: every push builds the site once per target---clearnet and Tor---and rsyncs each to its own web root, so the two stay in sync without any manual work.³

That's it. Read this site over Tor at dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion.

Open it in the Tor Browser. There is no certificate authority, no DNS, and no exposed IP---the address is derived directly from a public key, and the connection is end-to-end encrypted by Tor itself. ↩
Tor stores the service's private key and hostname file here and insists on owning it (chmod 700, user debian-tor). Point it at your site files and Tor refuses to start. ↩
See First Steps on a New Server for the underlying machine; the full configuration lives in my homelab repository, and the site's own repository holds the GitHub Actions workflow that builds and deploys the Tor copy. ↩

[Boost]

David Álvarez Rosa — Sun, 24 May 2026 09:58:02 +0000

David Álvarez Rosa

May 23

Devirtualization and Static Polymorphism

#computerscience #cpp #performance #programming

4 min read

Devirtualization and Static Polymorphism

David Álvarez Rosa — Sat, 23 May 2026 21:36:21 +0000

Ever wondered why your "clean" polymorphic design underperforms in benchmarks? Virtual dispatch enables polymorphism, but it comes with hidden overhead: pointer indirection, larger object layouts, and fewer inlining opportunities.

Compilers do their best to devirtualize these calls, but it isn't always possible. On latency-sensitive paths, it's beneficial to manually replace dynamic dispatch with static polymorphism, so calls are resolved at compile time and the abstraction has effectively zero runtime cost.

Virtual dispatch

Runtime polymorphism occurs when a base interface exposes a virtual method that derived classes override. Calls made through a Base& are then dispatched to the appropriate override at runtime. Under the hood, a virtual table (vtable) is created for each class, and a pointer (vptr) to the vtable is added to each instance.

On a virtual call, the compiler loads the vptr, selects the right slot in the vtable, and performs an indirect call through that function pointer. The drawback is that the extra vptr increases object size, and the indirection through the vtable makes the call hard to predict. This prevents inlining, increases branch mispredictions, and reduces cache efficiency.

The best way to observe this phenomenon is by inspecting the assembly¹ code emitted by the compiler for a minimal example

class Base {
public:
  auto foo() -> int;
};

auto bar(Base* base) -> int {
  return base->foo() + 77;
}

For a non-virtual member function foo like in the example above, the free function bar issues a direct call

bar(Base*):
        sub     rsp, 8
        call    Base::foo()  // Direct call
        add     rsp, 8
        add     eax, 77
        ret

However, declaring foo as virtual changes bar's assembly into an indirect, vtable-based call

bar(Base*):
        sub     rsp, 8
        mov     rax, QWORD PTR [rdi]  // vptr (pointer to vtable)
        call    [QWORD PTR [rax]]     // Virtual call
        add     rsp, 8
        add     eax, 77
        ret

Devirtualization

Sometimes the compiler can statically deduce which override a virtual call will hit. In those cases, it devirtualizes the call and emits a direct call instead (skipping the vtable). For example, devirtualization is straightforward² when the runtime type is clearly fixed

struct Base {
  virtual auto foo() -> int = 0;
};

struct Derived : Base {
  auto foo() -> int override { return 77; }
};

auto bar() -> int {
  Derived derived;
  return derived.foo();  // compiler knows this is Derived::foo
}

The compiler is able to devirtualize even through a base pointer, as long as it can track the allocation and prove there is only one possible concrete type. The problem is that with traditional compilation, object files are created per translation unit (TU)---compiled and optimized in isolation. The linker simply stitches those objects together, so cross-TU optimizations are inherently limited. That's where compiler flags are useful.

-fwhole-program
: tells the compiler "this translation unit is the entire program." If no class derives from Base in this TU, the compiler is free to assume nothing ever does, and can devirtualize calls on Base.

-flto
: link-time optimization. Keeps an intermediate representation in the object files and optimizes across all of them at link time, effectively treating multiple source files as a single TU.

On the language side, final is a lightweight way to give the compiler the same guarantee for specific methods

class Base {
public:
  virtual auto foo() -> int;
  virtual auto bar() -> int;
};

class Derived : public Base {
public:
  auto foo() -> int override;  // override
  auto bar() -> int final;     // final
};

auto test(Derived* derived) -> int {
  return derived->foo() + derived->bar();
}

Here, foo() can still be overridden, so derived->foo() remains a virtual call. However, bar() is marked as final, so the compiler emits a direct call even though it's declared virtual in the base

test(Derived*):
        push    rbx
        sub     rsp, 16
        mov     rax, QWORD PTR [rdi]
        mov     QWORD PTR [rsp+8], rdi
        call    [QWORD PTR [rax]]       // Virtual call
        mov     rdi, QWORD PTR [rsp+8]
        mov     ebx, eax
        call    Derived::bar()          // Direct call
        add     rsp, 16
        add     eax, ebx
        pop     rbx
        ret

Static polymorphism

When the compiler can't devirtualize, one option is to use static polymorphism instead. The canonical tool for this is the Curiously Recurring Template Pattern³ (CRTP). With CRTP, the base class is templated on the derived class, and invokes methods on it via static_cast---no virtual keyword involved

template <typename Derived>
class Base {
public:
  auto foo() -> int {
    return 77 + static_cast<Derived*>(this)->bar();
  }
};

class Derived : public Base<Derived> {
public:
  auto bar() -> int {
    return 88;
  }
};

auto test() -> int {
  Derived derived;
  return derived.foo();
}

With -O3 optimization, the compiler inlines everything and constant-folds the result. No vtable, no vptr, no indirection. Fully optimized⁴ call.

test():
        mov     eax, 165  // 77 + 88
        ret

Deducing this. C++23's deducing this keeps the same static-dispatch model but makes it easier to write. Instead of templating the entire class (and writing Base<Derived> everywhere), you template only the member function that needs access to the derived type, and let the compiler deduce self from *this

class Base {
public:
  auto foo(this auto&& self) -> int { return 77 + self.bar(); }
};

class Derived : public Base {
public:
  auto bar() -> int { return 88; }
};

This yields identical optimized code: foo is instantiated as foo<Derived>, and the call to bar is resolved statically and inlined.

Assembly generated with gcc at -O3 on x86-64. Similar results were observed with clang on the same platform. ↩
The compiler emits a direct call to Derived::foo (or inlines it), because derived cannot have any other dynamic type. ↩
The curiously recurring template pattern is an idiom where a class X derives from a class template instantiated with X itself as a template argument. More generally, this is known as F-bound polymorphism, a form of F-bounded quantification. ↩
The trade-off is that each Base<Derived> instantiation is a distinct, unrelated type, so there's no common runtime base to upcast to. Any shared functionality that operates across different derived types must itself be templated. ↩