Resident resource experiment56d: implementation and execution boundaries

한국어 · Preserved pre-execution design · Go implementation

This stage measures the cost of starting a small hint tool once and sending many requests. It is not Laya model inference or training. Repeated resource observations are separate from semantic utility on independent requests. This implementation explanation precedes collection and asserts neither successful measurements nor completed CI.

What runs

Project only requests and candidate captions from the existing72 public parents. Select parents originally containing three candidates; retain the first raw representative when normalized text features match. Preserve original parent/candidate IDs and selection/exclusion reasons as metadata. IDs, truth and candidate source do not enter ranking features. Preparation must confirm at least two distinct feature payloads.

Store exact compact JSON bytes as base64 so indenting the enclosing JSON cannot change transmitted bytes. Append exactly one LF and enforce12KiB including LF. Raw wire SHA, input digest and normalized feature SHA have different purposes. Normalization removes punctuation; feature SHA is not a safe cache key for narrow_rule, which reads raw grammar.

The actual child is riido-shortclaim --stream. Four Go baselines (fixed_order, bm25, lexical_ordered, narrow_rule) recompute preparation, validation, ordering, digest and output for each request. Expected responses are protocol comparisons generated by the same public implementation before replay, not independent truth labels. All candidates remain available and responses retain unverified_heuristic status.

Fixed before observing results

Item	Execution policy
Matrix	four baselines × same/distinct × three fresh children =24 rows
Requests per row	first1 + warmup20 + timed1024 =1045
Pool position	each of first, warmup and timed starts at position0
Row order	repeats1/3 forward, repeat2 reversed; workload order alternates
Limits	child15s, replay60s, shared cleanup1000ms; stop after first failed row
Concurrency	one child, one request in flight, zero automatic retries
Go configuration	Go1.27.1, CGO0, trimpath, GOMAXPROCS1,256MiB heap soft limit
New public data	corpus, plan, preparation, recipe and results JSON together ≤8MiB

The25,080 requests and24,576 timed observations are repetitions. They do not add independent training requests or supply a2400-request final evaluation. Fresh children are not OS-cache-cold; no cache flush runs. Go P count and soft heap limit do not impose hard limits on OS threads or total memory.

The driver compares22 compiled source byte streams against repository bytes. Freeze24 runtime files including separate child sources, two module files and five pre-collection tests:31 file pins. Reject unlisted implementation files. Freeze the build recipe, both actual binary SHAs/buildinfo, original input SHAs, platform-specific protocol expectation bytes and24-row order before official replay.

The CLI checks only the40-character format of preparation_source_commit. A separate freeze operation checks that31 Git blobs at that commit match the planned source hashes and records the result. Do not describe the CLI as verifying Git history. Supply the plan SHA independently. Run a private copy of the child bytes already read and hash-verified; publish neither binaries nor private paths.

Reading CPU, memory and timing

After child exit, record user/system CPU and lifetime peak RSS. Separately record controller replay CPU delta and controller lifetime peak RSS including preparation. This child launches no subprocesses. Go ProcessState exposes OS resource information, and its CPU APIs describe the exited process and its children. Do not generalize this observation to an arbitrary process tree.

Linux peak RSS uses KiB in getrusage. Darwin's XNU resource implementation uses resident_size_max, whose field definition specifies bytes. Retain original units and converted bytes. Adding separate process peaks does not establish a simultaneous total peak. RSS is not Go heap, GPU memory or current warm memory.

Timed RTT starts before writing and ends on a complete response line. Controller validation spans receipt through validation completion; separately record delivery gap and validation work. Pure startup, child processing and pipe time remain unobserved. Per-row expected stream hashing occurs before child spawn but inside global replay CPU/wall. Do not add or subtract overlapping clocks to infer hidden costs.

Complete-row CPU/request divides by1045, including first and warmup requests. Timed latency divides by1024. Failed rows retain actual attempted/written/received/validated/failed/incomplete/not-attempted counts and available CPU/RSS, never a1045-success average. Keep subsequent unstarted rows. Reaping, stdout/stderr readers and the cancellation watcher share one1000ms cleanup budget. Record late cleanup or exceeded60s rather than replacing the run with an automatic retry.

Preparation versus official execution

--stage prepare writes corpus.json, preparation.json and build-recipe.json to a new directory. Child requests, model calls, fits and protected-final reads are zero. Small fake processes, malformed responses, timeout controls and packaged build comparisons validate the collector; they are not the official resource matrix. They perform no new candidate semantic truth audit.

Official --stage replay requires a frozen plan SHA, corpus and actual packaged child. It refuses existing output and reserves the new results file before starting a child. Record protocol mismatch, stderr, timeout and exit failures using fixed error names; publish no private arguments or raw stderr. Add observed results and CI links only after collection, in a separate results document.

Caching, SIMD, locks, SoA, open-loop concurrency and echo controls remain separate follow-up plans. Semantic utility and at least2400 distinct protected-final requests per domain are also separate. Training, new models, weights, automatic activation and asserted LLM savings are zero in this stage.