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.
41 lines
2.2 KiB
TeX
41 lines
2.2 KiB
TeX
\section{Comparison with Zero-Copy Protocols}
|
|
|
|
%% ============================================================================
|
|
|
|
ZAP, Cap'n Proto, and FlatBuffers all claim ``zero-copy'' semantics. This section distinguishes them.
|
|
|
|
\subsection{Architectural Differences}
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\caption{Zero-copy protocol architecture comparison}
|
|
\label{tab:zerocopy}
|
|
\begin{tabular}{lllll}
|
|
\toprule
|
|
\textbf{Property} & \textbf{ZAP} & \textbf{Cap'n Proto} & \textbf{FlatBuffers} \\
|
|
\midrule
|
|
Layout & Fixed offset & Pointer segments & Vtable + offsets \\
|
|
Codegen required & No & Yes (.capnp) & Yes (.fbs) \\
|
|
Schema evolution & Manual versioning & Built-in & Built-in \\
|
|
Pointer traversal & None & Per-field & Per-field (vtable) \\
|
|
Arena reuse & Yes (builder.Reset) & No (new segment) & Partial \\
|
|
EVM native types & Yes (Address, Hash) & No & No \\
|
|
Max message size & 10 MB (configurable) & 4 GB (segments) & 2 GB \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{Why ZAP is Faster Than Cap'n Proto}
|
|
|
|
Cap'n Proto uses a segment-based memory model with far pointers. Accessing a field requires: (1) read the pointer word, (2) decode the offset and segment, (3) validate bounds, (4) dereference. ZAP's fixed-layout design eliminates steps 1--3: field access is \texttt{buf[offset:offset+size]}, which compiles to a single indexed load.
|
|
|
|
The performance difference is measurable: ZAP's 6.4 ns/op decode vs.\ Cap'n Proto's 11.2 ns/op (1.75$\times$). For a consensus message with 6 field accesses, this compounds to $6 \times (11.2 - 6.4) = 28.8$ ns saved per message, or 1.44M additional messages/sec on a single core.
|
|
|
|
\subsection{Why ZAP is Faster Than FlatBuffers}
|
|
|
|
FlatBuffers uses a vtable to support schema evolution. Each field access requires: (1) read vtable offset, (2) check if field is present, (3) compute field position, (4) read value. ZAP eliminates the vtable entirely, trading schema evolution for raw speed.
|
|
|
|
In consensus protocols, message schemas are fixed by the protocol specification and change only with hard forks. The vtable flexibility is unused overhead. ZAP's design choice---no vtable, no schema evolution, maximum speed---is correct for this domain.
|
|
|
|
%% ============================================================================
|