# New document I've run `frun` benchmarks against `rust-parallel`:
frun beat rust-parallel on 178 of the 180 comparable tests, with no failures on either side. The margin falls into two very different regimes, so a single average is misleading. These figures are geometric means across the three input files and the four I/O variants. | Workload | Tests | frun lines/s | rust-parallel lines/s | frun speedup | Range | | ------------------------------------ | ----- | ------------ | --------------------- | ------------ | -------------- | | Per-line commands: `-X`, `-k -X` | 72 | 12.3M | 16.9k | 729x | 105x to 1062x | | Stdin line batches: `-s` vs `--pipe` | 36 | 13.1M | 5.7M | 2.3x | 1.1x to 4.8x | | Stdin 512 KiB blocks | 36 | 13.5M | 5.5M | 2.5x | 1.1x to 4.5x | | Stdin 4 KiB blocks | 36 | 6.3M | 4.4M | 1.4x | 0.92x to 6.3x | | All comparable tests | 180 | | | 21x | 0.92x to 1062x | Speedup by input file: | Workload | f1, empty lines | f2, `seq` | f3, file paths | | -------------------- | --------------- | --------- | -------------- | | Per-line commands | 976x | 941x | 422x | | Stdin line batches | 1.2x | 2.2x | 4.5x | | Stdin 512 KiB blocks | 1.5x | 2.4x | 4.3x | | Stdin 4 KiB blocks | 1.2x | 1.2x | 1.9x | What the numbers mean: * **Per-line work is where the gap is.** rust-parallel starts one process per input line, so it stays near 17k lines/s whatever the input. frun packs thousands of lines into each command. * **Streaming is close.** With `--pipe`, rust-parallel runs at 40 to 85% of frun's speed on small lines. frun's lead grows on the larger f3 input. * **frun lost only with 4 KiB byte chunks.** Its `cat` and `tee` runs on f2 scored 0.94x and 0.98x. frun's own throughput halves there, which suggests per-chunk overhead. * **Wall time differed hugely.** frun needed 44 seconds for its 396 tests, and rust-parallel needed 72 minutes for 180. * **frun's extra modes have no rust-parallel equivalent.** Its `-u`, `-U` and `-l 1:-1` modes ran at 12 to 13M lines/s. Correctness: * **Neither tool had a failed test.** The only line-count differences come from word splitting. * **rust-parallel splits each input line on whitespace.** On f3, file paths containing spaces became extra arguments, giving 1,027,558 output lines instead of 1,000,000. For file lists, treat that as a real correctness difference. * **frun's** `-U` mode splits the same way. That is its documented unquoted behaviour. Caveats, which mostly understate frun: * **Input size.** At 1M lines, frun's fixed startup of about 55 ms is a large share of each test. On the 100M-line file, the same `-X true` command reached about 70M lines/s instead of 17M. * **THP setting.** Shmem transparent huge pages were set to `never`. frun's help says `always` makes its stdin modes 50 to 60% faster. * **Machine load.** The load average was 0.4 when the run started, so contention was low. On Wed, 30 Sept 2026 at 14:06, Martin MΓΈller Skarbiniks Pedersen < [email protected]> wrote: > On Tue, 29 Sept 2026 at 11:22, nadim khemir <[email protected]> > wrote: > >> Hi, is there a chance you'd do the same comparison you did before with >> the forkrun project found at https://github.com/jkool702/forkrun? >> >> >> Small test from me. The documentation for forkrun documentation "*drop-in > replacement for GNU Parallel"* > > $ time parallel -j0 ping -c 1 10.1.13.{} ::: {1..255} | grep "64 bytes" > [...] > 64 bytes from 10.1.13.246: icmp_seq=1 ttl=64 time=0.667 ms > > real 0m10.783s > user 0m0.591s > sys 0m1.384s > > $ time frun -j0 ping -c 1 10.1.13.{} ::: {1..255} | grep "64 bytes" > 64 bytes from 10.1.13.246: icmp_seq=1 ttl=64 time=1.53 ms > > real 1m5.372s > -- Alan Silva π²πββπββπ§π·π«π·π¬π§
