papers/lux-zap-benchmarks/sections/14-named-competitor-comparison.tex

\section{Named-Competitor Comparison Scaffold}
\label{sec:zap-named-comp}
%% ============================================================================

The benchmark tables in Tables~\ref{tab:encode}--\ref{tab:zerocopy}
report ZAP against six wire protocols on Lux internal hardware.
This section pins those competitors to their \emph{published, externally
reproducible} numbers and marks the ZAP column \texttt{[TBD-measure]} so
the comparison can be re-run with audited numbers on each side.

\subsection{Competitors and Published Numbers}

\begin{itemize}
  \item \textbf{Protobuf}~\cite{protobuf} --- the reference varint-encoded
        format used by gRPC. Published Go benchmark
        (\texttt{kcchu/buffer-benchmarks}) reports encode 883.8\,ns/op,
        decode 1{,}179\,ns/op; \texttt{gogofaster} variant 384.4 / 496.2
        ns/op~\cite{kcchubuffer}.
  \item \textbf{FlatBuffers}~\cite{flatbuf} --- Google's zero-copy
        binary format. \texttt{chronoxor/CppSerialization} benchmark
        reports decode $\sim$81\,ns/op @ 12.3M ops/s~\cite{chronoxorbench}.
  \item \textbf{Cap'n Proto}~\cite{capnp} --- Kenton Varda's zero-copy
        format. \texttt{kcchu/buffer-benchmarks} reports encode
        1{,}709\,ns/op, decode 830.8\,ns/op~\cite{kcchubuffer}.
  \item \textbf{gRPC / Protobuf}~\cite{grpc,protobuf} --- complete
        Go RPC stack; tail latencies dominated by TLS + HTTP/2 framing
        + GC; see \cite{grpcperformance}.
  \item \textbf{QUIC}~\cite{quic} --- raw IETF RFC 9000 transport,
        no schema layer.
  \item \textbf{JSON-RPC} --- textual baseline.
\end{itemize}

\subsection{Per-Message Encode/Decode Scaffold}

\begin{table}[h]
\centering
\small
\begin{tabular}{@{}lrrl@{}}
\toprule
\textbf{Format} & \textbf{Encode (ns/op)} & \textbf{Decode (ns/op)} & \textbf{Source} \\
\midrule
\textbf{ZAP}                       & \texttt{[TBD-measure]} & \texttt{[TBD-measure]} & this paper \\
\midrule
Protobuf (Go)                      & 883.8 & 1{,}179 & \cite{kcchubuffer} \\
Protobuf (\texttt{gogofaster})     & 384.4 & 496.2   & \cite{kcchubuffer} \\
FlatBuffers (Go)                   & 856.8 & 18.89   & \cite{kcchubuffer} \\
FlatBuffers (C++, deserialise)     & ---   & $\sim$81 (12.3M ops/s) & \cite{chronoxorbench} \\
Cap'n Proto (Go)                   & 1{,}709 & 830.8 & \cite{kcchubuffer} \\
Cap'n Proto (Go, packed)           & 2{,}591 & 1{,}716 & \cite{kcchubuffer} \\
Protobuf (C++, deserialise)        & ---   & $\sim$351 (2.85M ops/s) & \cite{chronoxorbench} \\
\bottomrule
\end{tabular}
\caption{Published encode/decode numbers for the named competitors.
Numbers are quoted verbatim from the cited public benchmark
repositories; the ZAP cell stays \texttt{[TBD-measure]} until ZAP is
run \emph{inside the same harness} on the same machine.}
\label{tab:zap-lit-encode-decode}
\end{table}

\subsection{Tail-Latency / Allocation Scaffold}

\begin{table}[h]
\centering
\small
\begin{tabular}{@{}lrrl@{}}
\toprule
\textbf{Protocol stack} & \textbf{Decode allocs} & \textbf{p99 round-trip} & \textbf{Source} \\
\midrule
\textbf{ZAP}                       & \texttt{[TBD-measure]} & \texttt{[TBD-measure]} & this paper \\
\midrule
gRPC / Protobuf (Go, blocking)     & 3 (192\,B/op)        & milliseconds-class       & \cite{kcchubuffer,grpcperformance} \\
FlatBuffers (zero-copy, in-proc)   & 0                    & not directly comparable  & \cite{chronoxorbench} \\
Cap'n Proto (zero-copy, in-proc)   & 0                    & not directly comparable  & \cite{kcchubuffer} \\
JSON-RPC (Go, blocking)            & many (varies)        & milliseconds-class       & \cite{kcchubuffer} \\
\bottomrule
\end{tabular}
\caption{Where ZAP must win to justify the abstract's tail-latency claim.
gRPC's p99 over a real TLS+HTTP/2 wire is dominated by stack effects,
not the protobuf encoder; ZAP must be measured against gRPC \emph{end-to-end}
to support the ``GC-induced consensus timeout'' argument.}
\label{tab:zap-lit-tail}
\end{table}

\subsection{Reproducibility Specification}
\label{sec:zap-repro}

\begin{itemize}
  \item \textbf{Hardware.} One physical \texttt{c6i.8xlarge} (Intel
        Ice Lake, 32 vCPU, 64\,GiB) for the encode/decode microbenches;
        a pair of \texttt{c6i.8xlarge} across two AZs for the
        end-to-end gRPC vs.\ ZAP round-trip measurement.
  \item \textbf{Software.} ZAP at the \texttt{luxfi/zap} HEAD listed in
        this paper's freeze; protobuf via \texttt{google.golang.org/protobuf}
        latest patch; gogofaster via \texttt{gogo/protobuf} v1.3.2;
        FlatBuffers via \texttt{google/flatbuffers} v24.x; Cap'n Proto
        via \texttt{capnproto/go-capnp/v3}.
  \item \textbf{Microbench harness.} Reuse the upstream
        \texttt{kcchu/buffer-benchmarks} harness verbatim, adding a
        ZAP backend. Numbers must be reported with the same
        \texttt{go test -bench=.} configuration the upstream uses.
  \item \textbf{Round-trip harness.} Two-node Go program; both nodes
        wired to ZAP and to gRPC; measure $10^7$ requests per
        configuration; report p50/p99/p99.9 with
        \texttt{hdrhistogram}; report GC counts via
        \texttt{runtime.MemStats}.
  \item \textbf{Decision rule.} ZAP ``wins'' only on the rows where it
        is run inside the same upstream harness. The current ZAP
        numbers in Tables~\ref{tab:encode}--\ref{tab:zerocopy} are
        Lux-internal and must be replaced (or annotated) with the
        upstream-harness numbers before the abstract's claims can be
        treated as comparable.
\end{itemize}

%% ============================================================================