Experiments

docs/benchmarking.md

@@ -72,6 +72,27 @@ benchmark.bat quick   rem рабочее исследование
 benchmark.bat full    rem финальные повторы, длительный запуск
 ```
 
+Отдельная large-матрица с обязательным reserved vector, fixed leaf 64…1024 и
+adaptive запускается внешним process pool. Второй аргумент — число workers:
+
+```bat
+large_benchmark.bat smoke 12
+large_benchmark.bat full 12 3
+large_benchmark.bat full 12 3 huge
+```
+
+Каждый worker закрепляется за отдельным logical CPU. Третий аргумент ограничивает
+число одновременно работающих N=100M-ячеек и лишь снижает риск pagefile; это
+эвристика, а не измеритель доступной памяти. Четвёртый аргумент `huge` оставляет
+только N=100M. Large raw,
+per-cell partial/log, план, environment и сводки сохраняются в отдельной папке
+`results/benchmarks/`.
+
+`large_benchmark.bat full 12 3 huge` воспроизводит только N=100M с удлинённым
+512-edit horizon и сам проверяет поддержку AVX2. Прямой PowerShell runner такой
+CPU-проверки не выполняет: при его ручном запуске `avx2` надо исключить на
+неподдерживаемой машине.
+
 Для публикации финального числа нужны одинаковый power plan, отсутствие тяжёлой
 фоновой нагрузки, закрепление на физическом ядре, randomized paired order и
 holdout workloads/seeds. Текущие quick-данные являются calibration set, а не

docs/findings.md

@@ -138,6 +138,28 @@ adaptive-deferred sequential `uint32` найден устойчивый AVX2 cod
 1.85–1.98x относительно baseline во всех пяти повторах при верных checksums.
 Он требует отдельного анализа generated code, а не постфактум объяснения SIMD.
 
+## Large-scale sweep до 100 миллионов элементов
+
+Серии [`large v1`](../results/benchmarks/20260811-large-full-12c-v1/README.md)
+и [`seed-jittered v2`](../results/benchmarks/20260811-large-n100m-512edit-12c-v2/README.md)
+сравнили reserved vector, fixed tiered leaf 64…1024 и текущий adaptive в
+12-worker pool; N=100M ограничивался тремя одновременными процессами. При
+N=100M и чистом чтении vector
+оказался примерно в 10.5 раза, а adaptive — в 8.7 раза быстрее лучшего fixed
+tiered. Уже при 0.01% равномерных middle-правок fixed стал примерно в 7.5 раза
+быстрее обоих.
+
+При 5–100% равномерных правок adaptive переключался в tiered и опережал vector
+примерно в 1.5–3 раза, но end-to-end оставался в сотни или тысячи раз медленнее
+fixed oracle: до первого перехода он успевал выполнить сотни O(N)-сдвигов.
+Каждый переход выбрал leaf1024, хотя лучший fixed leaf менялся от 64 до 1024.
+Следовательно, текущая главная проблема — позднее накопление evidence и слабый
+выбор geometry, а не churn, который уже ограничен hysteresis.
+
+Эти числа являются co-scheduled throughput, а не изолированной latency: workers
+делят L3/DRAM, а N>1M имеет один repeat на профиль. Поэтому SIMD-профили сохранены
+отдельно, но точный AVX2 speedup по этой серии не утверждается.
+
 ## Чего пока нельзя утверждать
 
 - Не доказано, что adaptive implementation уже имеет geometric mean > 1 против