1\section{End-to-end benchmarks}2\label{sec:e2e}34\paragraph{E1 --- batched realized measures on the real panel.} Table~\ref{tab:e1} and Figure~\ref{fig:e1} report the full estimator path (\texttt{realized\_measures\_batch}: the five fused accumulators, finite-sample constants, jump proxy, tripower quarticity and daily returns) on the 2024 panel, with segments of one day, one week, one month or one year of regular-session 1-minute returns, for panel widths of 1, 10, 100 and 926 symbols, and on a synthetic 10\,000-series panel. Three facts stand out. First, at the estimator level the GPU advantage is much smaller than at the kernel level: on 40 million real returns the 18-thread CPU needs 29--30\,ms and Metal 20--28\,ms (1.07--1.41$\times$), and at $4.8\times10^6$ returns or fewer the two are statistically tied or the CPU wins; the single-thread CPU is 8$\times$ slower than either. The CPU post-processing that the GPU does not remove---conversion to FP32, tripower in FP64, the per-segment finishing---bounds the achievable speedup (Amdahl's law), and the fused kernel's 2--3$\times$ on raw reductions shrinks accordingly. Second, kernel fusion matters more than the device: the four-kernel Metal variant is 1.4--3.2$\times$ slower than the fused one on the same data, because each extra pass re-reads the panel and pays its own launch and synchronisation. Third, accuracy is unaffected: the maximum relative difference between Metal and FP64 realized variance over all 926$\times$252 session segments is $1.6\times10^{-7}$ and decreases with segment length ($1.4\times10^{-8}$ for yearly segments), exactly the input-rounding behaviour predicted in Section~\ref{sec:metal}. Longer segments favour the GPU (month and year segments are the Metal wins); many tiny segments favour the CPU.56\begin{table}[t]7\centering\scriptsize8\caption{E1 --- batched realized measures (estimator path), laptop. Medians of 5 repetitions; ``real'' = 2024 FinData panel; ``synthetic'' = Student-$t(5)$ returns; max rel.\ err.\ = largest $|\RV_{\text{Metal}}-\RV_{\text{FP64}}|/\RV_{\text{FP64}}$ over segments.}9\label{tab:e1}10\resizebox{\textwidth}{!}{\input{tables/tab_e1}}11\end{table}1213\begin{figure}[t]14\centering\includegraphics[width=.95\textwidth]{figures/fig_e1.pdf}15\caption{E1 --- throughput (returns per second) of the realized-measures estimator by backend on the real and synthetic panels.}16\label{fig:e1}17\end{figure}1819\paragraph{E6 --- the Arrow/Parquet-to-estimator pipeline.} Table~\ref{tab:e6} compares, on four of the cached export files (2.2--2.5 million bars, 50 symbols, one year each), the \raid{} pipeline---Parquet read with column projection and threaded decoding, session filtering with the exact calendar, within-session log returns, and the five realized measures per session---with the same computation written in pandas, Polars (lazy scan) and DuckDB (SQL window functions). The baselines use an approximate early-close rule (fixed dates) because none of them ships an exchange calendar. \raid{} on the CPU processes a file in 0.118\,s (20 million bars per second), Polars in 0.165\,s and DuckDB in 0.164\,s (both 14 million bars per second), pandas in 2.56\,s. Within \raid{}, decoding the Parquet columns takes 0.065\,s, session filtering and returns 0.021\,s and the estimators 0.031\,s on the CPU; Metal makes the estimator stage slower (0.037\,s) because the stage is below the break-even size of E1 and the conversion is paid again. The answer to RQ3 is therefore moderate: a typed, projected, calendar-exact C++ pipeline is about 1.4$\times$ faster than the best columnar engines and 22$\times$ faster than pandas on this task, and the GPU plays no role in it. Before column projection was added, the same pipeline took 0.35\,s---reading eight of twenty columns instead of all of them, and avoiding the per-row string column, was worth more than any kernel. True zero-copy from Arrow to the estimators was possible for every file (single-chunk, null-free numeric columns), but the session filter necessarily materialises a selection; we count four column copies per file.2021\begin{table}[t]22\centering\small23\caption{E6 --- end-to-end pipeline per export file (median of 4 files $\times$ 3 repetitions; 2.37 million bars per file).}24\label{tab:e6}25\resizebox{\textwidth}{!}{\input{tables/tab_e6}}26\end{table}27