from-entangled-v2 continuous-v3 beta-schedule Profile

Back to design Back to results

Runtime Snapshot

• runs analyzed: 36
• mean wall time from run_start to run_end: 1.23h
• median wall time: 1.00h
• range: 0.50h to 3.12h
• slowest mean tasks: base_conversion 1.97h, sorting_algorithms 1.57h, multidigit_addition 1.28h
• fastest mean tasks: linear_equation_solving 0.80h, list_summation 0.80h, grid_pathfinding 0.96h

Mean wall time by task:

Coarse Runtime Sections

The strongest split that the event logs support is:

1. repeated pre-epoch intervals between run_start / step checkpoints / epoch_end
2. the final tail from epoch_end to run_end

At the collection level:

• mean time before the final epoch-end checkpoint: 1.07h
• mean final tail after epoch_end: 0.16h
• mean final-tail share of total runtime: 11.81%

So the bulk of runtime is not in finalization. Roughly 88% of wall time is spent before the last epoch-end checkpoint, inside the repeated training-plus-evaluation windows between checkpoint markers.

Which Sections Take The Most Runtime

Because checkpoint saves are point events rather than long spans, the dominant runtime must sit in the long intervals between them. The event-log summary shows:

Observed section-level facts:

• The single longest interval is usually the opening run_start -> step_200 block. It is the longest interval in 30/36 runs, with mean duration 13.6 minutes.
• The repeated checkpoint-to-checkpoint windows still dominate total runtime because there are many of them. Each later interval is only about 6.8 to 7.8 minutes on average, but there are seven such windows before epoch end.
• The final tail after epoch_end is shorter than the full pre-epoch portion, but it is not negligible. Its mean is 9.5 minutes and it reaches 30.4 minutes in the slowest runs.

The practical implication is that checkpoint writing itself is not the main wall-time sink here. The expensive part is the repeated work happening between those checkpoint markers, especially the opening block and the accumulation of the later step-to-step windows.

Task Dependence

Task still drives most observed wall-time variation even with this coarse measurement:

• base_conversion has the slowest mean total runtime (1.97h) and also one of the largest final tails (0.28h)
• sorting_algorithms is next slowest at 1.57h with a similarly large final-tail share (14.64%)
• list_summation and linear_equation_solving are the fastest tasks and also have the smallest final tails

This matches the coarse event-log picture that slow runs are slow throughout the repeated pre-epoch windows rather than only at the end.

Aggregate Comparison With continuous-v2

At the collection level, this sweep is much shorter on average than the earlier from-entangled-v2/continuous-v2 collection:

• current continuous-v3 beta-schedule mean runtime: 1.23h from event-log wall time
• prior continuous-v2 mean runtime: 10.26h from profiler-measured in-process wall time
• simple aggregate delta: -9.03h on the mean, or about 8.3x lower runtime in the current collection

This is not a perfectly apples-to-apples profiler comparison because the measurement sources differ. Even so, the gap is large enough to be operationally meaningful. A plausible collection-level explanation is that continuous-v3 beta-schedule uses the much smaller scheduled-validation generation budget eval_generation_num_samples=1000, whereas the continuous-v2 profiling note attributes most runtime to repeated router-sampled validation generation and reports that collection with eval_generation_num_samples=None.

Limits

• There is no profiler section table for this collection, so this note cannot say whether train compute, router-sampled evaluation, validation-loss evaluation, or output writing dominates within each interval.
• The event-log analysis supports only coarse wall-time attribution.
• If a later follow-up needs true section shares like the continuous-v2 profiling note, the collection has to be rerun with profiling enabled.