Manaka benchmarks

Manaka's current absolute speed is summarized in the common benchmark. This page keeps the Manaka-specific measurement interpretation and commands.

Current measurements

At 360398d:

Training

Default d128_o3_h512_pair16:

GPU	best measured batch	pos/s
RTX 4070 Ti	4096	104,579
A100-SXM4-80GB	2048	117,059
RTX 5060	2048	58,080

The A100 gain is modest for this workload. Batch width helps until the device is filled, then flattens; it is not safe to infer the best width from DLManaka's behavior.

CPU search

search_speed, 5,000 simulations, one core:

CPU	sims/s	nps	evals/s
Core Ultra 7 265KF P-core	22,329	22,334	29,608
Core i5-14400	16,411	16,414	23,736
EPYC 7742	4,411	4,412	11,006

The EPYC host was busy during measurement; do not use that row as a clean CPU comparison.

Evaluation versus search cost

On the 265KF, eval_split attributes roughly three quarters of one simulation to evaluator arithmetic and the remainder mainly to tree/search logic. Move generation itself is a small fraction.

The default evaluator runs about 494k MACs per position. This is why shrinking dense widths has a much larger inference effect than changing a lookup table by a small number of channels.

Incremental update

eval_throughput evaluates different positions once each:

mode	265KF throughput
warm accumulator update	28,550 pos/s
cold accumulator rebuild	19,389 pos/s

The 1.47× gap is the measured benefit of carrying the accumulator between positions on this CPU.

Parallel self-play

On the 265KF, one process with shared parameters scaled to 371,498 sims/s at 20 threads. Twenty independent processes reached 246,556 sims/s because each replicated the 176 MB pair table. manaka-selfplay uses the shared-table/thread design.

Feature-space experiments

The 2026-08-26 search_speed run found the narrow KP shape much faster than the wide Manaka-style head. The important interpretation is that network width, not KP itself, produced most of the speed difference.

HalfKP rows from that run are not valid playing-speed measurements: a king move renumbers all HalfKP features, while the current four-token delta cannot update them correctly. Treat HalfKP speed as unknown until king-move refresh is implemented.

See the feature-space measurement for the validation trade-off.

Commands

Training benchmark setup:

cargo build --release -p manaka-train --features cuda

Search and evaluator benchmarks:

cargo run --release -p manaka-core --example search_speed
cargo run --release -p manaka-core --example eval_throughput

Measurement rules

• Use the common benchmark for current cross-machine ratios.
• Copy a benchmark binary aside before timing if other sessions may rebuild the same tree.
• Clear WANDB_API_KEY when logging would contaminate timing.
• Check GPU co-tenancy before and after training runs.
• Do not treat sims/s changes as pure evaluator speed when weights change the search-tree shape; use tree-free evaluator measurements when that distinction matters.