Forkrun
NUMA-aware shell parallelizer (50×–400× faster than parallel)
Details
- External ID
- 47541746
- Source
- HN
- Company
- —
- Product
- Forkrun
- Website domain
- github.com
- Launched
- March 27, 2026
- Cohort
- —
- Upvotes
- 151
- Upvotes percentile
- 0.9446494464944649
- Tags
- —
- Fetched at
- Sept. 7, 2026, 9:26 p.m.
- Updated at
- Sept. 7, 2026, 9:26 p.m.
Description
forkrun is the culmination of a 10-year-long journey focused on "how to make shell parallelization fast". What started as a standard "fork jobs in a loop" has turned into a lock-free, CAS-retry-loop-free, SIMD-accelerated, self-tuning, NUMA aware shell-based stream parallelization engine that is (mostly) a drop-in replacement for xargs -P and GNU parallel.On my 14-core/28-thread i9-7940x, forkrun achieves:* 200,000+ batch dispatches/sec (vs ~500 for GNU Parallel)* ~95–99% CPU utilization across all 28 logical cores, even when the workload is non-existant (bash no-ops / `:`) (vs ~6% for GNU Parallel). These benchmarks are intentionally worst-case (near-zero work per task) because they measure the capability of the parallelization framework itself, not how much work an external tool can do.* Typically 50×–400× faster on real high-frequency low-latency workloads (vs GNU Parallel)A few of the techniques that make this possible:* Born-local NUMA: stdin is splice()'d into a shared memfd, then pages are placed on the target NUMA node via set_mempolicy(MPOL_BIND) before any worker touches them, making the memfd NUMA-spliced. Each numa node only claims work that is already born-local on its node. Stealing from other nodes is permitted under some conditions when no local work exists.* SIMD scanning: per-node indexers/scanners use AVX2/NEON to find line boundaries (delimiters) at speeds approaching memory bandwidth, and publish byte-offsets and line-counts into per-node lock-free rings.* Lock-free claiming: workers claim batches with a single atomic_fetch_add — no locks, no CAS retry loops; contention is reduced to a single atomic on one cache line.* Memory management: a background thread uses fallocate(PUNCH_HOLE) to reclaim space without breaking the logical offset system.…and that’s just the surface. The implementation uses many additional systems-level techniques (phase-aware tail handling, adaptive batching, early-flush detection, etc.) to eliminate overhead, increase throughput and reduce latency at every stage.In its fastest (-b) mode (fixed-size batches, minimal processing), it can exceed 1B lines/sec.forkrun ships as a single bash file with an embedded, self-extracting C extension — no Perl, no Python, no install, full native support for parallelizing arbitrary shell functions. The binary is built in public GitHub Actions so you can trace it back to CI (see the GitHub "Blame" on the line containing the base64 embeddings). Trying it is literally two commands: . frun.bash frun shell_func_or_cmd < inputs For benchmarking scripts and results, see the BENCHMARKS dir in the GitHub repoFor an architecture deep-dive, see the DOCS dir in the GitHub repoHappy to answer questions.
Enrichment
- Theme
- lightweight and on-device AI runtimes
- Vertical
- Horizontal
- Function
- Dev tools
- Audience
- Developer
- AI stance
- Not AI
- Project type
- Hobby / open-source project
- Normalized one-liner
- numa-aware shell parallelizer
- Manually corrected
- False
Could you build this?
No Forkrun relies on a decade of low-level systems programming involving NUMA memory layouts, SIMD acceleration, lock-free ring buffers, and OS scheduling internals that cannot be hallucinated or vibe-coded.
What it would actually take: The software is written in low-level C or Assembly-optimized POSIX shell helpers, interfacing directly with Linux kernel scheduler topologies, hwloc/libnuma, and CPU vector registers (AVX/NEON). The hard engineering problem is eliminating compare-and-swap (CAS) contention loops and cache-line bouncing during ultra-high-throughput IPC between hundreds of spawned sub-processes. This demands world-class systems programming expertise, CPU architecture profiling, and deep mastery of operating system concurrency primitives.
Discussion
20 comments analyzed.
Competitors mentioned: GNU Parallel, rush, SLURM, MPI
Concerns raised: 80ms startup overhead not amortized for small workloads, Linux-only, doesn't work in Cygwin, Slower than rush in small job batches (14k files), Requires substantial supporting machinery setup
Feature requests: Packaging for various Linux distributions, Integration with make for BSD/GNU make versions, Support for Windows/Cygwin environments
Competitors
Other products that read as similar to this one — 260 launches clear the similarity bar, closest 8 shown.
Attention rank: #17 of 261 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).
Launched 149 days after the earliest competitor.
- Numax · hn · 2026-06-16 · 6 upvotes · similarity 0.52
- Optimizing LiteLLM with Rust · hn · 2025-11-18 · 27 upvotes · similarity 0.52
- Sub-millisecond VM sandboxes using CoW memory forking · hn · 2026-03-17 · 311 upvotes · similarity 0.48
- I made an open-source Rust program for memory-efficient genomics · hn · 2025-11-13 · 17 upvotes · similarity 0.47
- lsm-engine · github · 2026-09-12 · 16 upvotes · similarity 0.47
- RunMat · hn · 2025-12-02 · 21 upvotes · similarity 0.46
- Threadprocs · hn · 2026-03-23 · 64 upvotes · similarity 0.45
- BVisor · hn · 2026-02-23 · 24 upvotes · similarity 0.45
Other launches for this product
- No other launches for this product.
Same idea, different domain
Nobody's really built a dev tools tool for Sales yet.