A machine can have an elegant way of representing a problem and still be a poor tool for solving it quickly. The Prime Clockwork gives each discovered prime a repeating residue state. A literal scan updates those states as each integer arrives. Could the same idea work better if it only acted when a composite was due?
In one small Python comparison, an event queue made the literal clockwork scan much faster. But a standard segmented sieve was faster still. The result is about three specific implementations on one machine, not a general contest between mathematical ideas.
From ticking clocks to scheduled marks
In the minimal clockwork scan, each discovered prime p has a residue that advances at every candidate integer. When the residue completes a cycle, the candidate is divisible by p and is rejected. This is easy to follow, but it updates every existing prime state at every step.
The event-queue version stores the next multiple of each prime in a priority queue. When prime p is found, its first event is placed at p². At each candidate n, every event due at n is advanced by p; if at least one was due, n is composite. If no event was due, n is emitted as prime and its own event stream begins at n².
This is the familiar sieve-of-Eratosthenes idea represented as scheduled composite marks. A due event proves that n is composite. Conversely, the least prime divisor of any composite n has already been found and marks n no later than n. This event schedule is not a new sieve or prime-generation theorem.
The measured comparison
The three implementations listed the primes through N=20,000. Each returned the same 2,262 primes as a separate trial-division reference. The retained run used Python 3.14.7 on macOS 27.0.1 arm64, with one warm-up and five timed samples per implementation in rotated order.
| Implementation | Counted work | Retained median | 26 October reproduction median | Traced Python allocation peak |
|---|---|---|---|---|
| Minimal clockwork scan | 24,068,809 clock updates | 1.00454 s | 1.04452 s | 169,352 bytes |
| Event heap | 35,485 composite marks; 73,232 heap operations | 0.02093 s | 0.02185 s | 193,184 bytes |
| Segmented sieve | 35,485 composite marks; 34 base primes | 0.000553 s | 0.000592 s | 90,567 bytes |
In the retained run, the event heap was about 48 times faster than the literal scan. The segmented sieve was about 38 times faster than the event heap. The second run returned the same prime lists and operation counts, with different timings; both records remain available in the Ledger artifact.
The table also shows why the number of composite marks is not enough to predict runtime. The event heap and segmented sieve marked the same number, but their data structures and operations cost different amounts in this implementation.
What the result leaves open
This is one bound, one Python version, one macOS arm64 machine and five timed samples. There is no cross-machine comparison or confidence interval. Counter collection was disabled during timing, but the code's conditional counter branches remained. The literal scan and event heap also differ in when work begins, so this run does not isolate one change as the cause of their timing difference.
The memory figures in the table are Python allocation-tracing peaks, not resident memory. Time and memory thresholds were checked after each run rather than enforced by the operating system; they are not resource guarantees. Small and segment-boundary cases were not separately recorded, and the broader benchmark contract remains incomplete, including resident-memory measurement and separately timed audit costs.
For this workload, the event queue improves on ticking every clock at every integer, while the ordinary segmented sieve remains the faster measured implementation. That is a useful bounded comparison, not a practical speed recommendation for other machines, larger ranges or different uses of the Clockwork representation.
The full implementation, retained raw results, separate reproduction results and source map are in the Research Artifact Ledger artifact, its source-to-claim map and benchmark script. The Prime Clockwork paper, version 1 is the source for the underlying representation; it does not contain or validate this event-queue comparison.
AI assistance disclosure
AI assisted with research, coding, drafting and editorial development.
OpenAI GPT models, accessed through Codex, materially assisted source and reference checks, analysis and implementation of the bounded comparison, review of the benchmark procedure and result interpretation, preparation and revision of this text, and creation of the conceptual cover. The measured values and code are documented in the cited Research Artifact Ledger records; the model-assisted checks do not constitute independent human benchmark review, mathematical specialist review or peer review. The author is responsible for the work. The retained research record does not provide a complete model-version history, and no complete history is claimed. The cover is an AI-generated conceptual illustration, not a benchmark result.
No published comments yet.