Very interesting!
On Wed, Sep 30, 2026 at 7:04 PM Alan <[email protected]> wrote:
>
> # 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 🚲🏊♂🏃♂🇧🇷🇫🇷🇬🇧
