# Pearl Miner T4: результаты 17 октября 2026

## Выбранная конфигурация

Tesla T4, M=N=K=8192, rank=128, все 8192³ INT8 MAC за попытку.
Программа сохраняет 16 слов transcript на каждую плитку 16×16, с обновлением
после каждого накопленного шага K=128. Проверки target и PlainProof сохранены.

Настройки финального ELF по умолчанию:

```text
gpu-device=0
gpu-kernel=93
gpu-schedule=ordered
threads=1
device-depth=2
pipeline=on
audit-every=256
worker=gpu1
```

Ядро: `mma-large-b256x96-w4x3-k128-prefetch-false-group16`.
Используется Turing PTX `mma.sync.aligned.m8n8k16` с INT32-накоплением,
shared-memory reuse и объединением XOR/rotate transcript по подгруппам.
Подготовка следующего входа и передачи перекрываются с вычислением;
compute-поток упорядочен, у каждой попытки собственные transfer-события.

## Производительность полного цикла

Время включает подготовку на CPU, compact input, H2D, восстановление шума,
полный накопительный GEMM/transcript, D2H, SIMD BLAKE3/target scan и
периодический аудит официальной математикой. Сетевого ожидания здесь нет.

| Конфигурация | Медиана повторных устойчивых скоростей, TMAC/s | Медианы трёх повторов |
|---|---:|---|
| №93, ordered, depth 2, 1 CPU worker | **13,975** | 14,149; 13,975; 13,664 |
| №93, concurrent, depth 2, 1 CPU worker | 13,677 | 13,6115; 13,677; 13,899 |
| №119, concurrent, depth 2, 1 CPU worker | 13,6405 | 13,921; 13,593; 13,6405 |

Каждый финальный повтор выполнял 512 полных циклов. Перед контрольной серией
выполнено 1024 цикла прогрева. Медиана полной скорости выбранных повторов,
включая инициализацию процесса/матриц, — **13,417 TMAC/s**. Базовый CUDA WMMA
вариант №0 с последовательным циклом показал 1,963 TMAC/s после старта:
итоговый вариант быстрее примерно в **7,1 раза** при одинаковой математике.
Это сравнение с базовым CUDA-бэкендом, а не с TPU.

Ориентир по числу проверяемых tile hashes: 13,975 TMAC/s соответствует
примерно 6,66 млн/с при данной геометрии. Это производная вычислительная
метрика, не количество принятых шар и не обещание доходности.

Короткие прогоны на холодной карте доходили примерно до 15–16 TMAC/s;
не следует использовать их вместо повторных прогретых полных циклов.
Частоты и температура зависят от выделенной Colab VM. `gpu_end` в JSON
снят после прогона и не является измерением частоты под постоянной нагрузкой.
Абсолютный максимум для любой T4 этими опытами не доказан.

Первичная серия schedule-screening выбрала №119, который измерялся раньше
и на более холодной GPU. Поэтому выполнен отдельный прогрев и сравнение
№93/№119 в повторных сериях; финальные defaults выбраны по последнему отчёту.

## Проверка вычислений

| Проверка | Результат |
|---|---|
| Все 126 конфигураций, малые/неполные блоки, K до 8192 | NumPy INT32, PASS |
| Все 126 конфигураций, полная матрица 8192³ | 528 482 304 слова transcript совпали с отдельным PyTorch/cuBLAS-эталоном |
| Compact noise + четыре различных полных входа, concurrent | 16 777 216 слов, PASS |
| То же, ordered | 16 777 216 слов, PASS |
| Четыре одновременные попытки, ожидание в разном порядке | PASS в обоих режимах |
| Повторное ожидание, неверный размер входа | PASS |
| Отмена/дренирование и последующая замена B | PASS в обоих режимах |
| Официальные Rust Legacy/Salted tile proofs | 528 GPU-доказательств, PASS; испорченные transcript отвергнуты |
| Разные входы, serial против очередей depth 2/3/4 | Побитовое равенство, PASS |
| Финальный ELF: CPU fast math/proofs/target tests | PASS |
| Финальный ELF: GPU proofs, runtime queues, 256 полных циклов | PASS |

Эталон полного transcript выполняет отдельную последовательность rank-128
произведений, INT32-накопления и XOR/rotate, а не вызывает проверяемое CUDA-ядро.
Для compact-input теста CPU отдельно восстанавливает sparse signed noise.
Только сравнение serial/async одного ядра не считалось достаточной проверкой
математической правильности.

## Что было перебрано

126 конфигураций охватывают global/shared WMMA, явный Turing MMA, формы block/
warp tiles, глубину K-stage, register prefetch, группы XOR/rotate 32/16/8/4/2/1,
увеличенную shared memory и 8/16/24/32 warp occupancy. Prefetch, более глубокая
очередь и дополнительные CPU workers не дали устойчивого общего выигрыша.
У многих вариантов дополнительный контроль, shuffle или регистры перевесили
уменьшение загрузок/редукций.

A передаётся компактно: 2 098 176 байт вместо 67 108 864, затем восстанавливается
на GPU. B передаётся/транспонируется один раз для job key и остаётся в GPU.
Pinned staging, stream/event и device buffers переиспользуются.

Первые resident/host-grid опыты выполнялись на VM, которая затем исчезла из
Colab CLI. Полные сырые таблицы этой VM не сохранены; её notebook history
выгружен отдельно и не входит в публичный архив. После восстановления заново
проверены все 126 ядер, оба режима жизненного цикла и финальное сравнение
производительности. Приведённые выше точные числа взяты из сохранённых JSON.

## Реальная шара через релей

Финальный ELF прошёл полный цикл на Colab T4 через
`stratum+quic://terminal01.nu11-p0inter.ru:13599`: TLS certificate/hostname,
ALPN `pearl-stratum/1`, object authorize, Salted job (`cert_version=3`),
per-MAC target, GPU-вычисления, локальный официальный verifier, отправка
PlainProof и положительный Stratum-ответ.

```text
SHARE_SENT id=2 job=0d08f012_2097152 proof_bytes=267249
SHARE_ACCEPTED id=2 job=0d08f012_2097152 accepted=1
submitted=1 accepted=1 rejected=0 exit_code=0
elapsed_seconds=255.99034667015076
```

Указан только пользовательский релей; автоматического перехода к адресу
upstream-пула нет. Включены `--stop-after-shares 1` и ограничение pending
submission, поэтому после первой принятой шары процесс завершился сам.
Сохранённый бинарный proof и его effective-target/job JSON дополнительно
проверены финальным ELF на Debian CPU без GPU и сети:
`PLAIN_PROOF_CHECK=PASS exact_pool_target=PASS`.

SHA-256 proof: `f1ca2ae717853b02e8a5cd53fa6176fcb1d2e20656c2a51c148a3855a45966e9`.
Кандидатный hash, little endian:
`12c96b50bea67b34ca33fa76037ebab51558f8842838601fdb0d539500000000`.
Proof/сырые журналы сохранены отдельно; публичный `real-relay-test.json`
содержит итог и интервальные скорости. Одна принятая шара подтверждает
совместимость этого полного цикла; это не длительный тест стабильности.

## Среда, сборка и артефакты

Тесты: Tesla T4 SM 7.5, 15 360 MiB, NVIDIA driver 580.82.07, CUDA 13.0.88,
Colab с двумя CPU. Сборка ELF: Debian 13, GCC 14.2, Rust 1.99.1,
`nvcc -O3 -std=c++17 -arch=sm_75`, Cargo `--locked --release --features cuda`,
`RUSTFLAGS=-C target-cpu=x86-64`. CPU AVX2 выбирается во время исполнения.

Один ELF включает CUDA runtime статически. Python/JAX/libtpu и CUDA Toolkit
во время запуска не нужны. Требуются совместимый NVIDIA driver, Linux x86-64,
glibc >=2.38 и доступные системные libstdc++/libgcc/libm. Файл проверен на
Debian без GPU для CPU-команд и на Colab T4 для вычислений/сети. Другие GPU
и более старые системы не проверялись. Стек ELF помечен RW без исполнения.

Существующий опубликованный TPU-файл `pearl-miner` сохраняется. Новый
`pearl-miner-t4` — отдельная CUDA-сборка; launcher выбирает backend по T4
или явному `PEARL_DEVICE`. Его offline-проверка покрыла auto T4, TPU env,
relay/finite-limit arguments, отклонение плохой SHA-256 и защиту живого PID.

Исходные архивы и их различия описаны в `ARCHIVE-AUDIT.md`. Полные актуальные
хеши исходников находятся в `SOURCE_AUDIT_MANIFEST.json` и `SHA256SUMS`.
Хеш готового ELF поставляется отдельно в `pearl-miner-t4.sha256`.

Сохранённые первичные отчёты:

- `recovery-all-kernels.json`;
- `recovery-bridge-concurrent.json`, `recovery-bridge-ordered.json`;
- `schedule-tuning.json` — первичный screen, не окончательные defaults;
- `thermal-confirmation.json` — окончательное повторное сравнение;
- `final-gpu-checks.log` — проверки поставляемого ELF;
- `real-relay-test.json` — ограниченная проверка одной принятой шары;
- `final-elf-metadata.json` — SHA-256 и системные зависимости ELF.