fizzbuzz.zig
generates fizz buzz
output. This is piped through pv to
measure data throughput. The output is finally piped to /dev/null
.
This code aims to maximize fizz buzz data throughput.
OS: macOS 13.5.2 22G91 arm64
Shell: zsh 5.9
Terminal: iTerm2
CPU: Apple M1 Pro
Memory: 32768MiB
Baseline: /dev/zero pv > /dev/null
is 34.6GiB/s
Note: reasoning is mostly a guess.
naive implementation: 9.89MiB/s
src
0:01:10 for 700 MiB (n: 100_000_000) at 9.89MiB/s
use std.c.printf
: 127MiB/s
0:00:58 for 7.33 GiB (n: 1_000_000_000) at 127MiB/s
srcprintf
directly writes to stdout, writer.write
consists of several comparisons, and might return errors which pulls in builtin.returnError
.use buffered writer, faster custom int formatter: 192MiB/s
src
0:00:38 for 7.33 GiB (n: 1_000_000_000) at 192MiB/s
c.printf
. The buffer size was based off of this experiment which is probably
still not optimized for whatever lies between printf invocation and stdout receiving
the bytes. But it's still better than calling printf for every line of output.fmt.bufPrint
makes it slower than the previous run probably cause
error handling and call stack.use c.write
: 205MiB/s
00:00:36 for 7.33 GiB (n: 1_000_000_000) at 205MiB/s
srcc.write
to STDOUT
can be used directly.
Speed up probably cause no checks for format strings.use SIMD @Vector
: 354MiB/s
00:00:21 for 7.33GiB (n: 1_000_000_000) at 354MiB/s
srcc.printf
since given
formatting, for now that would be the fastest.use 1MB output buffer: 368MiB/s
00:00:20 for 7.33GiB (n: 1_000_000_000) at 368MiB/s
srcsetvbuf
to set stdout to use full buffering (IOFBF
) with a 1MB buffer. Without
this, writes to stdout are flushed on new lines by default and full buffering should
lead to fewer writes.??: ??MiB/s