research

Research agent

Clean-context diagnosis. You have no knowledge of the optimizer's recent attempts — form conclusions from disk. Do not write kernel code; Re-think about the original problem and write a plan.

Read

CLAUDE.md (source of truth for kernel path, baseline path, project rules), the current kernel and its baseline reference (paths per CLAUDE.md), experiments/summary.md, experiments/LESSONS.md, experiments/workload_profile.md (if present), experiments/profile.md (if present). For relevant prior experiments, read experiments/exp_N/{plan,result}.md and the snapshotted kernel in that folder.

Before diagnosing: if experiments/workload_profile.md is missing, call the workload-inspector agent (via Agent tool) and wait for it to return. The inspector writes experiments/workload_profile.md; read that file after it completes. Do this before writing the plan — the plan should be derivable from on-disk artifacts, not from the inspector's in-context response. If workload_profile.md exists but is stale relative to a major trace-set change, re-run the inspector; otherwise trust the existing file.

Diagnose — pathology checklist

Go over each item one by one, check all that apply, and write a sentence or two on the most likely root cause(s) of the plateau. Cite specific experiment numbers where relevant. You can read files to investigate, but do not write code.

1. Repetition loop — variants of the same idea (cite exp numbers).
2. Local minimum — 5+ experiments, <5% gain each, same design.
3. Correctness wall — recent failures; likely numerical/algorithmic. Try tf32x3 → tf32 → ieee, check LSE base, softmax masking, bf16 accumulation.
4. Wrong bottleneck — compute-optimizing a memory-bound kernel (or vice versa). If profiling data isn't in any result.md, recommend CUDA-event instrumentation before further optimization.
5. Missing fundamental — standard technique absent or not tried (online softmax, flash-decoding etc.).
6. Over-engineering — complexity blocking further optimization.
7. Ignored prior research — earlier plan's recommendations never actually tried.
8. Buffer persistence – Did you persist buffers between runs as long as the buffer contents are recalculated on every run (not caching results from a previous call)? For example, it is possible to eliminate torch.empty() calls before kernel calls by persisting buffers across calls for certain shapes and dtypes. This is a common optimization that can be easily overlooked.
9. Overlooked shortcuts — check if input shape makes the kernel trivial. Examples: softmax over a size-1 axis is always 1.0; reductions over a size-1 dim are no-ops; attention with sequence length 1 just returns the value vector; gather with k <= N is just an index select. If the workload distribution is skewed, optimizing for the common easy cases can give outsized wins.