51 lines
1.4 KiB
Markdown
51 lines
1.4 KiB
Markdown
# Time Model and Cycles
|
|
|
|
Status: pedagogical
|
|
Companion spec: [`../specs/01-time-model-and-cycles.md`](../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.
|