OpenBSD is so fast, I had to modify the program slightly to measure itself

Original Article ↗ Hacker News Discussion ↗

OpenBSD vs Linux Performance (General)

  • Several comments argue Linux is usually significantly faster than OpenBSD (e.g. “3x faster”), attributing this to OpenBSD prioritizing security and simplicity over aggressive optimization.
  • Others push back that “it depends” heavily on workload: Linux may be faster for many general workloads, but BSDs can excel in specific areas (e.g. some networking paths, historical RNG performance).
  • One view is that OpenBSD is “lightweight/compact” but not “fast,” and not ideal for databases or fileservers; others disagree and note recent performance improvements and better SMP unlocking.

The Actual Benchmark: FD Table Growth and RCU

  • The discussed benchmark stresses file descriptor (FD) allocation with two threads rapidly creating sockets.
  • On Linux, the per-process FD table starts at 256 entries. When it needs to grow (256→512→1024), expand_fdtable() may call synchronize_rcu() if multiple threads share the file table.
  • synchronize_rcu() waits for a full RCU grace period, introducing multi‑millisecond stalls and making FD allocation look very slow.
  • A workaround in the test (dup2(0, 666)) pre-expands the table in single‑threaded context (refcount = 1), avoiding RCU and eliminating the slowdown.
  • OpenBSD uses a simpler rwlock around FD table modification and no RCU here, so it doesn’t hit this pathological latency for this synthetic test. FreeBSD similarly doesn’t use RCU for this path.

Random Number Generation and Security Tradeoffs

  • Some recall that historically OpenBSD’s /dev/urandom was dramatically faster than Linux’s blocking RNG behavior, especially before Linux moved to modern CSPRNGs (ChaCha20, etc.).
  • Others note that /dev/random vs /dev/urandom semantics and security–speed tradeoffs matter, and that today both Linux and BSDs use CSPRNGs with continuous reseeding.

Benchmarking Techniques and Timing Sources

  • There is debate over using different hardware and microbenchmarks; some call this “play” rather than serious benchmarking.
  • Discussion covers timing tools: __rdtsc() vs gettimeofday/clock_gettime via vDSO, issues with TSC synchronization, frequency scaling, and when cycle vs wall‑clock measurements are appropriate.

OpenBSD Design Choices and Security Posture

  • Comments mention OpenBSD’s kernel relinking at every boot (KARL) and relinking of core libraries/sshd for address randomization, trading boot time for attack complexity.
  • Opinions differ on whether OpenBSD remains meaningfully “more secure” than Linux today or simply adopts different security strategies, constrained by smaller developer resources.

Website UX and Distractions

  • A substantial subthread criticizes the page’s “asteroid/cannon” cursor game: moving bullets obscure text and hide the cursor, making the article unreadable for some and raising accessibility concerns.
  • Others defend such playful UI as adding personality, but several readers resort to ad‑block filters, reader mode, or mirrors to read the content.