Benchmarks & research

How to read these pages

These pages collect our measurements. Each one states its configuration (players, stacks, tree, abstraction, iterations, hardware), the metric used, and what the result does and does not show.

• An experiment is not a general claim. A result on one lab tree, one board or one set of ranges shows what happens there. Where we generalise, we say so and explain why.
• Lab trees are small on purpose. Many convergence tests use 3-max, 50bb, one bet size per street, so that a run finishes in hours and can be repeated.
• Hardware. Unless stated otherwise, timings are from an Intel i5-1235U laptop (2 performance cores and 8 efficiency cores, 64 GB installed RAM, Windows 11). A desktop CPU with more cores will be faster.

A checklist for screenshots and published ranges

A screenshot needs enough context to identify its game. Include player count, stacks, action line, rake, tree and whether the strategy is averaged, current or a re-solved node. A first-in grid is not a defence range, and a no-probe tree is not unrestricted postflop play.

For speed, state the CPU, threads, RAM, start street, stopping criterion and whether setup-table generation was included. For memory, distinguish peak process use from file size. A smaller compressed blueprint does not prove a smaller training working set.

Do not turn one test into a product-wide ranking. A reference comparison is useful only for the stated matched configuration. The 100 bb full-size run measures cost and convergence with no donk or probe bets; it has no independent reference equilibrium for that tree. Its screenshots are examples, not universal opening charts.