WP28: macro name fix, final validated build
4 changed files +3 −3
modified
experiments/make_tables.py
+1 −1
@@ -278,7 +278,7 @@ def main(): | |||||
| 278 | "benchRoundsPsixtyfourOneTwo": f"{G('cmp_p64_r1q2','t_rounds'):.2f}", "benchDerMaxPsixtyfour": f"{G('cmp_p64_r2q1','der_max'):.2f}", "benchUpPsixtyfourTwoOne": f"{G('cmp_p64_r2q1','up_B')/1e3:.0f}", | 278 | "benchRoundsPsixtyfourOneTwo": f"{G('cmp_p64_r1q2','t_rounds'):.2f}", "benchDerMaxPsixtyfour": f"{G('cmp_p64_r2q1','der_max'):.2f}", "benchUpPsixtyfourTwoOne": f"{G('cmp_p64_r2q1','up_B')/1e3:.0f}", | ||
| 279 | "benchUpTwoOne": f"{G('hosts16','up_B')/1e3:.1f}", "benchLocalHostsOne": f"{G('hosts1','t_local'):.2f}", "benchLocalHostsSixteen": f"{G('hosts16','t_local'):.2f}", "benchFitMeanHostsSixteen": f"{G('hosts16','fit_mean'):.2f}", | 279 | "benchUpTwoOne": f"{G('hosts16','up_B')/1e3:.1f}", "benchLocalHostsOne": f"{G('hosts1','t_local'):.2f}", "benchLocalHostsSixteen": f"{G('hosts16','t_local'):.2f}", "benchFitMeanHostsSixteen": f"{G('hosts16','fit_mean'):.2f}", | ||
| 280 | "benchRoundHostsOne": f"{1000*G('hosts1','t_rounds'):.0f}", "benchLatencyExcess": f"{1000*(G('hosts16','lat99') - G('hosts16','der_max')):.1f}", "benchLocalKonetwentyeight": f"{G('K128_r2q1','t_local'):.2f}", "benchRoundKonetwentyeight": f"{1000*G('K128_r2q1','t_rounds'):.0f}", | 280 | "benchRoundHostsOne": f"{1000*G('hosts1','t_rounds'):.0f}", "benchLatencyExcess": f"{1000*(G('hosts16','lat99') - G('hosts16','der_max')):.1f}", "benchLocalKonetwentyeight": f"{G('K128_r2q1','t_local'):.2f}", "benchRoundKonetwentyeight": f"{1000*G('K128_r2q1','t_rounds'):.0f}", | ||
| 281 | − "benchConnect": f"{G('hosts16','t_connect'):.1f}", "benchLocalPthirtytwoTwoOne": f"{G('p32_r2q1','t_local'):.2f}", "benchRoundPthirtytwoTwoOne": f"{G('p32_r2q1','t_rounds'):.2f}", "benchLocalPthirtytwoOneTwo": f"{G('p32_r1q2','t_local'):.2f}", "benchRoundsPthirtytwoOneTwo": f"{G('p32_r1q2','t_rounds'):.2f}", "benchLocalPthirtytwoThreeOne": f"{G('p32_r3q1','t_local'):.2f}", "benchLocalKtwofiftysix": f"{G('K256_r2q1','t_local'):.2f}", "benchRoundKtwofiftysix": f"{1000*G('K256_r2q1','t_rounds'):.0f}", "benchLat99Ktwofiftysix": f"{1000*G('K256_r2q1','lat99'):.0f}", "benchRuns": str(int(g.reps.sum())), "benchDerMaxPeight": f"{1000*G('hosts16','der_max'):.0f}"}) | 281 | + "benchConnect": f"{G('hosts16','t_connect'):.1f}", "benchLocalPthirtytwoTwoOne": f"{G('p32_r2q1','t_local'):.2f}", "benchRoundPthirtytwoTwoOne": f"{G('p32_r2q1','t_rounds'):.2f}", "benchLocalPthirtytwoOneTwo": f"{G('p32_r1q2','t_local'):.2f}", "benchRoundsPthirtytwoOneTwo": f"{G('p32_r1q2','t_rounds'):.2f}", "benchLocalPthirtytwoThreeOne": f"{G('p32_r3q1','t_local'):.2f}", "benchLocalKtwofiftysix": f"{G('K256_r2q1','t_local'):.2f}", "benchRoundKtwofiftysix": f"{1000*G('K256_r2q1','t_rounds'):.0f}", "benchLatNinetyNineKtwofiftysix": f"{1000*G('K256_r2q1','lat99'):.0f}", "benchRuns": str(int(g.reps.sum())), "benchDerMaxPeight": f"{1000*G('hosts16','der_max'):.0f}"}) | ||
| 282 | with open(TAB / "numbers.tex", "w") as f: | 282 | with open(TAB / "numbers.tex", "w") as f: | ||
| 283 | f.write("% Auto-generated by experiments/make_tables.py\n") | 283 | f.write("% Auto-generated by experiments/make_tables.py\n") | ||
| 284 | for k, v in macros.items(): | 284 | for k, v in macros.items(): | ||
modified
paper/main.pdf
+0 −0
Binary file not shown.
modified
paper/sections/benchmarks.tex
+1 −1
@@ -13,7 +13,7 @@ The protocol of \cref{alg:protocol} was run as written---a coordinator process a | |||||
| 13 | Three facts emerge, all specific to this hardware and implementation. First, the synchronized derivative phase is cheap: with $p = 8$ it takes \benchRoundTwoOne{} ms end to end on sixteen hosts, of which the slowest worker's score-and-Hessian evaluation accounts for \benchDerMaxPeight{} ms and the network round trip for about \benchLatencyExcess{} ms; the uplink of \benchUpTwoOne{} kB is irrelevant at these sizes. With $p = 64$ the phase takes \benchRoundPsixtyfourTwoOne{} s, almost all of it the slowest worker's computation of the $64 \times 64$ Hessian on $2^{18}$ observations (\benchDerMaxPsixtyfour{} s), with an uplink of \benchUpPsixtyfourTwoOne{} kB. At the intermediate dimension $p = 32$ the derivative phase takes \benchRoundPthirtytwoTwoOne{} s and the local phase \benchLocalPthirtytwoOneTwo{} s for one fit, \benchLocalPthirtytwoTwoOne{} s for the half-block pattern and \benchLocalPthirtytwoThreeOne{} s for the quarter-block pattern, so that $(1,2)$ costs $\benchLocalPthirtytwoOneTwo + \benchRoundsPthirtytwoOneTwo$ s against $\benchLocalPthirtytwoTwoOne + \benchRoundPthirtytwoTwoOne$ s for $(2,1)$. Second, the local phase dominates and grows with the order: at $p = 8$ the slowest worker needs \benchLocalOneTwo{} s for one fit, \benchLocalTwoOne{} s for the three fits of the half-block pattern, \benchLocalThreeOne{} s for the seven fits of the quarter-block pattern and \benchLocalFourZero{} s for the fifteen fits of order four; at $p = 64$ the half-block pattern costs \benchLocalPsixtyfourTwoOne{} s against \benchLocalPsixtyfourOneTwo{} s for one fit. Third, the exchange rate of \cref{prop:cost} therefore favours rounds on this network: at equal exponent $7/8$, $(1,2)$ is the fastest protocol at both dimensions ($\benchLocalOneTwo + \benchRoundsOneTwoS$ s against $\benchLocalTwoOne + \benchRoundTwoOneS$ s for $(2,1)$ at $p = 8$; $\benchLocalPsixtyfourOneTwo + \benchRoundsPsixtyfourOneTwo$ s against $\benchLocalPsixtyfourTwoOne + \benchRoundPsixtyfourTwoOne$ s at $p = 64$), and it is also the more accurate one (\cref{sec:mc}). The stale and single-machine variants save nothing here, because the derivative phase they shorten was already short; their statistical cost (\cref{thm:inexact}) is paid for no gain. In terms of \eqref{eq:rule}, the measured $\lambda + T_{\mathrm{der}} + Kb(p + p(p+1)/2)/B + T_{\mathrm{solve}}$ is two to ten times smaller than $r\,c_1 m$ at every $(r, p)$ tested, so the inequality holds and one more round beats one more level of local fits. | 13 | Three facts emerge, all specific to this hardware and implementation. First, the synchronized derivative phase is cheap: with $p = 8$ it takes \benchRoundTwoOne{} ms end to end on sixteen hosts, of which the slowest worker's score-and-Hessian evaluation accounts for \benchDerMaxPeight{} ms and the network round trip for about \benchLatencyExcess{} ms; the uplink of \benchUpTwoOne{} kB is irrelevant at these sizes. With $p = 64$ the phase takes \benchRoundPsixtyfourTwoOne{} s, almost all of it the slowest worker's computation of the $64 \times 64$ Hessian on $2^{18}$ observations (\benchDerMaxPsixtyfour{} s), with an uplink of \benchUpPsixtyfourTwoOne{} kB. At the intermediate dimension $p = 32$ the derivative phase takes \benchRoundPthirtytwoTwoOne{} s and the local phase \benchLocalPthirtytwoOneTwo{} s for one fit, \benchLocalPthirtytwoTwoOne{} s for the half-block pattern and \benchLocalPthirtytwoThreeOne{} s for the quarter-block pattern, so that $(1,2)$ costs $\benchLocalPthirtytwoOneTwo + \benchRoundsPthirtytwoOneTwo$ s against $\benchLocalPthirtytwoTwoOne + \benchRoundPthirtytwoTwoOne$ s for $(2,1)$. Second, the local phase dominates and grows with the order: at $p = 8$ the slowest worker needs \benchLocalOneTwo{} s for one fit, \benchLocalTwoOne{} s for the three fits of the half-block pattern, \benchLocalThreeOne{} s for the seven fits of the quarter-block pattern and \benchLocalFourZero{} s for the fifteen fits of order four; at $p = 64$ the half-block pattern costs \benchLocalPsixtyfourTwoOne{} s against \benchLocalPsixtyfourOneTwo{} s for one fit. Third, the exchange rate of \cref{prop:cost} therefore favours rounds on this network: at equal exponent $7/8$, $(1,2)$ is the fastest protocol at both dimensions ($\benchLocalOneTwo + \benchRoundsOneTwoS$ s against $\benchLocalTwoOne + \benchRoundTwoOneS$ s for $(2,1)$ at $p = 8$; $\benchLocalPsixtyfourOneTwo + \benchRoundsPsixtyfourOneTwo$ s against $\benchLocalPsixtyfourTwoOne + \benchRoundPsixtyfourTwoOne$ s at $p = 64$), and it is also the more accurate one (\cref{sec:mc}). The stale and single-machine variants save nothing here, because the derivative phase they shorten was already short; their statistical cost (\cref{thm:inexact}) is paid for no gain. In terms of \eqref{eq:rule}, the measured $\lambda + T_{\mathrm{der}} + Kb(p + p(p+1)/2)/B + T_{\mathrm{solve}}$ is two to ten times smaller than $r\,c_1 m$ at every $(r, p)$ tested, so the inequality holds and one more round beats one more level of local fits. | ||
| 14 | 14 | ||||
| 15 | \subsection{Hosts, processes and stragglers} | 15 | \subsection{Hosts, processes and stragglers} | ||
| 16 | −Spreading $K = 16$ workers from one host to sixteen (\cref{fig:bench}, right) does not speed up the local phase: its wall-clock is the slowest worker's, and the slowest of sixteen heterogeneous machines (a Mac mini) is slower than the slowest of sixteen processes on one Mac Studio (\benchLocalHostsSixteen{} s against \benchLocalHostsOne{} s), while the mean worker fit time is about the same (\benchFitMeanHostsSixteen{} s). The derivative phase roughly doubles from one host to sixteen (\benchRoundHostsOne{} ms to \benchRoundTwoOne{} ms), again through the slowest worker rather than through the network. With $K = 64$, $128$ and $256$ workers on sixteen hosts (four, eight and sixteen processes per host, $m = 2^{16}$, $2^{15}$ and $2^{14}$) the local phase falls to \benchLocalKonetwentyeight{} s and \benchLocalKtwofiftysix{} s for $(2,1)$ and the derivative phase to \benchRoundKonetwentyeight{} ms and \benchRoundKtwofiftysix{} ms (99th-percentile reply latency \benchLat99Ktwofiftysix{} ms with 256 connections): more partitions mean smaller blocks and faster local fits, but by \cref{thm:frontier} they also move the estimator towards the frontier, and the trade is statistical, not computational. The straggler excess, the gap between the slowest and the mean worker, is the quantity that an implementation should attack first; in these runs it comes from hardware heterogeneity rather than from the network. | 16 | +Spreading $K = 16$ workers from one host to sixteen (\cref{fig:bench}, right) does not speed up the local phase: its wall-clock is the slowest worker's, and the slowest of sixteen heterogeneous machines (a Mac mini) is slower than the slowest of sixteen processes on one Mac Studio (\benchLocalHostsSixteen{} s against \benchLocalHostsOne{} s), while the mean worker fit time is about the same (\benchFitMeanHostsSixteen{} s). The derivative phase roughly doubles from one host to sixteen (\benchRoundHostsOne{} ms to \benchRoundTwoOne{} ms), again through the slowest worker rather than through the network. With $K = 64$, $128$ and $256$ workers on sixteen hosts (four, eight and sixteen processes per host, $m = 2^{16}$, $2^{15}$ and $2^{14}$) the local phase falls to \benchLocalKonetwentyeight{} s and \benchLocalKtwofiftysix{} s for $(2,1)$ and the derivative phase to \benchRoundKonetwentyeight{} ms and \benchRoundKtwofiftysix{} ms (99th-percentile reply latency \benchLatNinetyNineKtwofiftysix{} ms with 256 connections): more partitions mean smaller blocks and faster local fits, but by \cref{thm:frontier} they also move the estimator towards the frontier, and the trade is statistical, not computational. The straggler excess, the gap between the slowest and the mean worker, is the quantity that an implementation should attack first; in these runs it comes from hardware heterogeneity rather than from the network. | ||
| 17 | 17 | ||||
| 18 | \subsection{Limits of the benchmark} | 18 | \subsection{Limits of the benchmark} | ||
| 19 | The measurements are for one cluster, one Python/NumPy implementation with pickle framing, one network, and $K \le 128$; they do not establish a general speed advantage of any protocol. On a network with latency of tens of milliseconds, or with bandwidth-limited uplinks of dense Hessians at large $p$, the left-hand side of \eqref{eq:rule} grows and the balance can tip towards local levels; the cost model is provided so that \eqref{eq:rule} can be evaluated with the parameters of a given installation. No energy or monetary cost was measured, and none is claimed. | 19 | The measurements are for one cluster, one Python/NumPy implementation with pickle framing, one network, and $K \le 128$; they do not establish a general speed advantage of any protocol. On a network with latency of tens of milliseconds, or with bandwidth-limited uplinks of dense Hessians at large $p$, the left-hand side of \eqref{eq:rule} grows and the balance can tip towards local levels; the cost model is provided so that \eqref{eq:rule} can be evaluated with the parameters of a given installation. No energy or monetary cost was measured, and none is claimed. | ||
modified
paper/tables/numbers.tex
+1 −1
@@ -71,6 +71,6 @@ | |||||
| 71 | \newcommand{\benchLocalPthirtytwoThreeOne}{7.67} | 71 | \newcommand{\benchLocalPthirtytwoThreeOne}{7.67} | ||
| 72 | \newcommand{\benchLocalKtwofiftysix}{0.11} | 72 | \newcommand{\benchLocalKtwofiftysix}{0.11} | ||
| 73 | \newcommand{\benchRoundKtwofiftysix}{8} | 73 | \newcommand{\benchRoundKtwofiftysix}{8} | ||
| 74 | −\newcommand{\benchLat99Ktwofiftysix}{6} | 74 | +\newcommand{\benchLatNinetyNineKtwofiftysix}{6} | ||
| 75 | \newcommand{\benchRuns}{75} | 75 | \newcommand{\benchRuns}{75} | ||
| 76 | \newcommand{\benchDerMaxPeight}{52} | 76 | \newcommand{\benchDerMaxPeight}{52} | ||
| 77 | 77 | ||||