Research-Pi: Skill for Claude Code

Experiment Systems Optimization

Shorten the time to valid experimental results. Optimize the experiment's code and execution plan; mature public library internals are the lowest priority. A faster equivalent algorithm, fewer repeated computations or a better CPU implementation may matter more than GPU tuning.

Start with resources and the whole system

Establish the target execution environment and what this experiment may use: CPU cores, RAM, GPUs and per-device VRAM, relevant storage/data location, sharing, and time or cost limits. Reuse known allocations and permissions. Inspect accessible state; when missing information would change the plan, ask the user directly or through the Leader. Do not confuse total capacity or momentary idle capacity with the experiment's allocation. Continue independent code analysis while an answer is pending.

Actively use available capacity to accelerate the experiment. Existing small batches, few workers, tiny caches or streaming one record at a time may be historical defaults, not constraints. Consider RAM preloading/caching, device residency, larger chunks and batches, CPU parallelism and independent-run concurrency. Account for intermediates, worker copies, queued inputs and variable-size peaks; choose headroom from the workload rather than an arbitrary large reserve. Seek useful throughput, not minimum memory usage or filling every device.

Map the complete experiment: reads, CPU preprocessing/simulation, task construction, IPC, device transfers, compute, CPU postprocessing, aggregation and storage. Identify dependencies, repeated work, data sizes, queue waits and overlap. Locate the critical path or the stage limiting sustained throughput before choosing a device or profiler. A long library call may reflect excessive calls, poor inputs or waiting for earlier asynchronous work.

Investigate and change the limiting mechanism

Form a few competing explanations when the cause is unclear. Include alternatives that change the calculation or execution structure, not just current parameters. Prefer the cheapest discriminating observation: existing timings, call counts, stage/queue timing, a bounded CPU sample or a short device trace when needed. Full profiling is not mandatory.