Buckets:
| # Compute estimate | |
| The original planning ranges were: | |
| - Configuration/data smoke: under one local CPU minute. | |
| - One bounded conic canary: 5-30 CPU minutes. | |
| - Main-text and coverage matrix (10,500 tasks): 12-72 aggregate CPU-hours if tasks terminate comparably to the author examples. | |
| - Complete 14,000-task suite: 24-144 aggregate CPU-hours, embarrassingly parallel, plus artifact upload time. | |
| The full-run estimate remains deliberately wide because the paper permits up to one million outer iterations and the released examples provide no paper-scale timing table. GPU requirement is zero. | |
| ## Measured optimizer timing | |
| All measurements below used a clean committed Windows CPU snapshot, one-thread BLAS, the independent solver, and claim-ineligible timing manifests. They spent $0. | |
| | Gate | Tasks | Updates | Internal wall | Trace bytes | Released stop observed | Outcome | | |
| |---|---:|---:|---:|---:|---:|---| | |
| | paper plain GD, fixed 100 | 21 | 2,100 | 14.7849 s | 12,708,904 | 5/21 | escalation required | | |
| | paper plain GD, fixed 1,000 | 16 | 16,000 | 69.6408 s | 96,246,799 | 0/16 | extrapolation denied | | |
| | paired optimizer fidelity, cap 250 | 8 | 1,752 | 8.3401 s | 2,944,376 | 1/8 | four-task diagnostic only | | |
| | paired stopping escalation, cap 5,000 | 8 | 33,964 | 138.0023 s | 52,739,104 | 2/8 | broader seeded timing required | | |
| The 100-step run had five released-code stop triggers, four caused by objective worsening. The 1,000-step escalation had no stop trigger, no solver-iteration deterioration, a maximum effective field-aware residual of `5.556315791781018e-8`, and one timing-drift failure. These runs establish per-update cost and solver health. They do not establish a stopping-time distribution, and they do not authorize a 14,000-task launch. | |
| The fixed-100 artifact is bound to run key `sha256:ad7abe12a3dd71b7d98b3e39598e28a1636d6d49238472698cdf94a8d8958f79` at commit `830741cd1e9afe10185e2ca69174a85dd8cfab28`. The fixed-1,000 artifact is bound to run key `sha256:5b0a8c2119f44254bd272fc766936a6ca04ebe86597d24ef6dec102a2eb3befa` at commit `f1711b2179ba1de61410fd9e088345ea04c969a6`. | |
| The paired 5,000-step escalation used the corrected paper and released-code stopping contracts. One positive-objective paper-GD route stopped at 3,962 iterations. The negative-objective paper-GD route stopped at two iterations because the paper's literal denominator inverted the improvement sign. Six routes reached the cap without a primary trigger. The run is bound to `sha256:c0d32dbaa3f5e3c19d6508f22d139068ea0d8ee1b080b3421f07b615903acb4f` at commit `f324f9ddffaf2e07684d9b3f7327261258bf2af8`. | |
| Across these four representative tasks and two optimizer routes, the mean was 17.25 seconds and 6.59 MB per trajectory. Applying those means mechanically to 14,000 tasks gives about 67.0 aggregate CPU-hours and 92.3 GB of uncompressed evidence. The CPU figure lies inside the original 24-144 hour range, but four tasks cannot freeze a portfolio estimate. The storage projection is already sufficient to reject a naive JSONL launch. The next execution gate must sample more seeds and adopt a lossless compact numeric trace format or compression while retaining independently validated scalar and checkpoint lineage. | |
| ## Measured out-of-sample timing | |
| Two grouped regression evaluations each processed exactly 10,000,000 OOS samples and five representative decisions. Together they took 5.56585 seconds internally: 0.22039 seconds sampling, 2.21513 seconds evaluation, and 0.21835 seconds aggregation. The bound run identity is `sha256:310a18e9c42d6d1ab3a2ea155d539242cdee7cbaec71587225d915b1bec313dd`. | |
| This OOS result covers only absolute and squared regression groups. It does not project the entire portfolio and leaves `cost_freeze_eligible: false`. | |
| Measured local evidence: the three-iteration Gaussian-portfolio `v3` canary, including 42 finite-difference re-solves, twenty bootstrap distances, and trace persistence, took 0.883218 seconds externally. This validates low-dimensional solver plumbing but is not a representative convergence timing sample and must not be linearly extrapolated to the full matrix. | |
| The canonical three-route Appendix `v2` bundle took 1.2794429 seconds externally. It included exact empirical OT solves, nonzero OT-envelope checks, conic-value checks, active-penalty checks, two outer steps per route, terminal re-solves, and trace persistence. It is likewise a plumbing measurement, not a convergence-cost estimate. | |
| The first clean stopping-rule canary used one Gaussian task, twenty bootstrap distributions, two outer steps, full gradient checks, and a terminal re-solve. It completed in **0.334499 seconds** on local Windows CPU. Multiplying this cold-process canary time by all 14,000 tasks gives **78.05 serial minutes**, but that is only a coarse projection for the implemented Gaussian route. It is not yet a defensible portfolio estimate because dimensions, route solvers, stopping lengths, process reuse, out-of-sample evaluation, and raw artifact writes vary by suite. | |
| No paid or remote run is authorized from these data. A compact optimizer-fidelity probe must first separate the paper Algorithm 2 stopping rule from the released-source stopping rule, measure the primary stopping-time tail, and replace full per-iteration state serialization with scalar iteration records plus bound checkpoints. | |
| As checked on 2026-07-19, Hugging Face Jobs lists `cpu-upgrade` as 8 vCPU / 32 GB at **$0.03 per hardware-hour**: `https://huggingface.co/docs/hub/en/jobs-pricing`. Under ideal eight-way utilization, the original 24-144 aggregate CPU-hour range corresponds to 3-18 hardware-hours, or **$0.09-$0.54**. With a 25% setup/persistence buffer, that would be **$0.12-$0.68**. This remains a planning range, not launch authority, because the measured 1,000-step gate did not identify the stopping-time distribution. | |
| ## Frozen 400-task stopping and storage diagnostic | |
| The first complete stratified diagnostic validated 400 of 400 tasks across 60 strata. Its sealed analysis identity is `sha256:9aaff11076c7fc7f7b3209e657e69b6901a7533c2bab9a1ce928629bf6dd1c8e`, bound to batch manifest `sha256:766069d5ee7be3ad37fa1a4d399fa943de78f6f8dd1022e46c7bfbf7d771bd35` and receipt set `sha256:1d35fff9002f0aae8228a3761e54ada917c7f54f4c5334bda99f228b176d2bf9`. Reanalysis produced the same identity. | |
| The point estimates at the 5,000-iteration diagnostic cap are 113,716.88 CPU-core-seconds, 2.7407 GB of artifacts, a 69.29% stopping-rule trigger probability, and a 30.71% censoring probability. These are diagnostic estimates only. The preregistered precision gate failed because the overall relative half-widths were 19.72% for runtime and 12.55% for storage, above the frozen 10% limit. Five non-regression suites also exceeded at least one frozen 20% per-suite limit. The result therefore has `precision_pass: false`, all scientific claims remain `HOLD`, and no full-matrix launch is authorized from it. | |
| The independent follow-up is frozen in `configs/stopping_storage_precision_followup_v1.json`. It draws a fresh SHA-ranked sample from the full 14,000-task population, preserves all 60 strata and the Gaussian main versus ablation pairs, and analyzes the follow-up independently. Its 2,580 tasks include 90 expected pilot overlaps by design. Those overlaps were rerun under the follow-up commit, so runtime evidence was not reused. The original 10% overall and 20% per-suite gates were unchanged. The launch controller was local only, used eight one-thread workers, issued tasks in a separately bound SHA-ranked order so the first 200 were interleaved across suites, evaluated a conservative wall projection after those 200 completions, and would have blocked further issuance if the projected upper wall exceeded 5,400 seconds. | |
| ## Frozen 2,580-task precision follow-up | |
| The clean execution used manifest `sha256:5e0f724f8faa52207cf8ce0df822db08c868541b369c54d9fa48b10df1a6543a` at commit `e5db1b7082b0056ad80695e0936100c15f9d5ee7`. All 2,580 tasks succeeded, no failure ledger was created, and the 200-task wall gate passed with a conservative projection of 3,811.84 seconds against the frozen 5,400-second limit. | |
| The validated aggregate identity is `sha256:65c51df2681e33ba1363341cd44bcfd8d094b8427cc599eb40ac6c1f95ae862d`. The sealed analysis identity is `sha256:4b2009f94a968455b96ec3f7c0a618cb446d4f3c67ec610f86e0180097e2c3b6`. A full independent reanalysis produced the same identity and file hash. | |
| At the 5,000-iteration diagnostic cap, the projected full-matrix requirements are 124,251.44 CPU-core-seconds, or 34.51 CPU-core-hours, and 2.9407 GB of artifacts. The projected stopping-rule trigger probability is 66.72%, leaving 33.28% censored at the cap. Overall relative half-widths are 5.71% for runtime and 6.03% for storage. All fourteen suite-by-metric checks pass the frozen 20% limit; the widest is 14.54% for Gaussian-main runtime. | |
| This gate authorizes only the diagnostic resource estimate. It does not freeze cost, authorize the full matrix, or support a paper claim. C1, C2, and C3 remain `HOLD`. Because roughly one-third of tasks are projected to reach the cap, a fresh-process checkpoint/resume canary is required before any full-matrix launch. | |
| ## Checkpoint/resume canary result | |
| The eight-task fresh-process canary passed from clean commit `654bce052ee076f65a1a38f06fdae769afb35403`. Its sealed receipt is `sha256:ae7f31368dc23426f43b9bd8e651596cd90b5020c861a89304337da9348a679d`, bound to manifest `sha256:559fe003a09b0b71457f125dc1fa42ff0c3e43aeb7907bbb5d987968c6853946`. All eight resumed candidates exactly matched distinct-identity uninterrupted oracles, including the terminal post-update solve. The closed 56-event lifecycle completed in 37.203 seconds, below the frozen 300-second cutoff, with all external authority denied. | |
| This result establishes that the saved Algorithm 2 state is sufficient for exact cold-process continuation on the frozen canary routes. It does not yet put checkpoint/resume into the production 14,000-task result schema, authorize the full matrix, freeze cost, or support C1-C3. The next gate must integrate the proven state and lifecycle contract into the production batch runner, then pass a bounded interrupted production-batch canary before a full launch. | |
Xet Storage Details
- Size:
- 10.3 kB
- Xet hash:
- 379c8ed28314c6eddc1efbd741f614d9c708c140176174efca9a25ffd1a148d6
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.