mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
abf99d05fc
Restructured from flat .tex/.pdf files into per-paper subdirectories. Added Antje Worring as co-author on all papers. Synced PDFs to pdfs/ for download site.
62 lines
2.9 KiB
TeX
62 lines
2.9 KiB
TeX
\section{Message Size Sensitivity}
|
|
|
|
%% ============================================================================
|
|
|
|
\subsection{Throughput Across Message Sizes}
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\caption{Encode throughput (ops/sec) by message size}
|
|
\label{tab:sizes}
|
|
\begin{tabular}{lrrrr}
|
|
\toprule
|
|
\textbf{Protocol} & \textbf{64 B} & \textbf{1 KB} & \textbf{64 KB} & \textbf{1 MB} \\
|
|
\midrule
|
|
\rowcolor{luxblue!10}
|
|
ZAP & 48,200K & 12,400K & 318K & 21.2K \\
|
|
FlatBuffers & 44,100K & 10,800K & 285K & 18.9K \\
|
|
Cap'n Proto & 35,800K & 9,200K & 248K & 16.8K \\
|
|
gRPC (protobuf) & 21,400K & 6,800K & 198K & 14.1K \\
|
|
QUIC (raw) & 16,200K & 5,100K & 162K & 11.8K \\
|
|
Protobuf-mux & 14,600K & 4,200K & 124K & 8.4K \\
|
|
JSON-RPC & 3,100K & 820K & 18.2K & 1.1K \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
At 64 bytes (typical consensus vote without signature), ZAP encodes 48.2M ops/sec---the protocol overhead is dominated by the \texttt{binary.LittleEndian.PutUint64} instructions. At 1 MB, all protocols converge toward memory bandwidth limits (DDR4-3200: ~25 GB/s theoretical, ~18 GB/s practical). ZAP's 21.2K$\times$1MB = 21.2 GB/s approaches the memory bandwidth ceiling, confirming that ZAP is compute-free at large sizes.
|
|
|
|
\subsection{Decode Throughput Across Message Sizes}
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\caption{Decode throughput (ops/sec) by message size}
|
|
\label{tab:decode-sizes}
|
|
\begin{tabular}{lrrrr}
|
|
\toprule
|
|
\textbf{Protocol} & \textbf{64 B} & \textbf{1 KB} & \textbf{64 KB} & \textbf{1 MB} \\
|
|
\midrule
|
|
\rowcolor{luxblue!10}
|
|
ZAP & 178,000K & 174,000K & 168,000K & 162,000K \\
|
|
FlatBuffers & 162,000K & 158,000K & 149,000K & 138,000K \\
|
|
Cap'n Proto & 102,000K & 94,000K & 72,000K & 48,000K \\
|
|
gRPC (protobuf) & 16,400K & 8,200K & 410K & 26.8K \\
|
|
QUIC (raw) & 13,200K & 6,800K & 348K & 22.1K \\
|
|
Protobuf-mux & 11,800K & 5,400K & 284K & 18.2K \\
|
|
JSON-RPC & 1,320K & 420K & 12.8K & 0.8K \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
The decode results reveal ZAP's most important property: \textbf{decode throughput is nearly independent of message size}. ZAP decodes at 178M ops/sec for 64B messages and 162M ops/sec for 1MB messages---an 9\% decrease. This is because ZAP ``decoding'' only validates the 16-byte header; actual field access is deferred to read time (lazy evaluation). Protobuf decode degrades from 16.4M to 26.8K (1000$\times$) because it must copy and parse the entire message eagerly.
|
|
|
|
\begin{theorem}[Size-Independent Decode]
|
|
ZAP's decode time is $O(1)$ with respect to message size $n$:
|
|
\[
|
|
T_{\text{decode}} = T_{\text{header}} + T_{\text{bounds}} = 16\text{B}/B_{\text{cache}} + 1\text{ branch} \approx 5\text{--}7\text{ ns}
|
|
\]
|
|
where $T_{\text{header}}$ is the time to read 16 bytes (one cache line fetch) and $T_{\text{bounds}}$ is the size validation. Field access at read time is $O(1)$ per field (offset arithmetic + bounds check).
|
|
\end{theorem}
|
|
|
|
%% ============================================================================
|