1.6 KiB
| id | ticket | title | created | tags | ||
|---|---|---|---|---|---|---|
| LSN-0017 | legacy-runtime-learn-import | Time Model and Cycles | 2026-03-27 |
|
Time Model and Cycles
Status: pedagogical
Companion spec: ../specs/01-time-model-and-cycles.md
PROMETEU treats time as an explicit part of the machine.
Core Idea
Nothing happens "for free" or "instantly". The programmer should think in terms of:
- machine rhythm;
- cost per frame;
- distribution of work over time;
- the architectural impact of when each system runs.
Why Cycles Instead of Milliseconds
Milliseconds vary with platform, jitter, and real hardware. Cycles provide a cost metric that belongs to the PROMETEU machine rather than to the host.
That makes it easier to compare solutions, teach cost, and reason about performance without hiding the bill behind the operating system.
Temporal Distribution As Design
One of the most important intuitions in PROMETEU is that optimization is not only about "doing less", it is about deciding when to do it.
Useful examples:
- AI at 30 Hz;
- pathfinding at 15 Hz;
- frame-count-driven timers;
- separation between heavy update work and presentation.
Why CAP Fits Here
CAP reinforces this reading of time as technical evidence. It does not exist to block execution, but to make visible:
- spikes;
- bottlenecks;
- cost distribution;
- temporal architecture decisions.
Teaching Value
This model helps teach:
- execution planning;
- technical tradeoffs;
- reading real profiling evidence;
- temporal organization as an architectural tool.