TT/PV interaction and unexpected SPRT results with PVS

[mazerfaker]

Hi everyone,

I've been working on a bitboard-based C++ engine that supports the UCI protocol. I’ve implemented pseudo-legal move generation, perft validation, and run SPRT tests for evaluating search improvements. The engine has basic evaluation and implements a standard Negamax framework.

The engine includes:
* Transposition Table with three types: PV, Alpha, Beta
* Quiescence search
* Killer moves, history heuristics
* MVV/LVA and insertion sort for move ordering
* Mate scoring normalization when storing/retrieving from TT
* Hash-based repetition detection
* Positional evaluation with piece-square tables and basic pawn structure analysis

I wanted to bring up two observations and ask for feedback, as I may be misunderstanding something about how TT interacts with PV, or how PVS affects Elo in early development stages.

Issue 1: PV tracking doesn’t seem to improve Elo when TT is enabled

I store the PV by following best moves recursively (triangular PV table), and I use the PV move from the TT to boost move ordering. However, in my SPRT tests, removing the PV-related logic (e.g., disabling PV tracking and ordering by PV move) made no measurable difference in Elo when the transposition table was enabled.

This makes me wonder:
* Is this expected?
* Could my TT already be effectively capturing enough of the PV path through its entries, making explicit PV tracking redundant?
* Or am I likely doing something wrong in how I apply PV ordering or update TT entries?

Issue 2: Adding PVS cuts node count in half but loses ~30 Elo

When I implemented Principal Variation Search (fail-soft + null-window searches), I observed a ~50% reduction in node count, which looked great. However, after running SPRT tests, it lost around 30 Elo compared to plain Negamax without PVS.

This was surprising—I expected the Elo to be neutral or slightly better.
My assumptions:
* Move ordering is decent (captures, killers, history, PV if enabled)
* TT is working and returns early cutoffs when applicable
* PVS is applied only for non-first moves

I'm wondering if this could be due to:
* Shallow null-window searches missing good scores due to imperfect ordering?
* Not deepening the first move enough in early iterations?
* My killer/history heuristics polluting the ordering too early?

I'm curious if others have observed similar behavior or can point out what I might be missing. Happy to share specific snippets if needed, and I’m open to all advice.

Thanks in advance!
—Max

[hgm]

The PV move should be the hash move, and most of the PV should be in the TT if you have some depth-preferred replacement. So I would not expect explicit PV tracking to make measurable difference.

A PVS search should deliver the same score and move as an alpha-beta search.