our_knp/cats-dogs/ACCELERATION.md
int 979aa90bb4 Add 2026-10-14 handoff materials, verify accelerated runs
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-14 18:29:08 +03:00

94 lines
12 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# CPU и GPU: что ускорено
## Чистый Linux против WSL
По запросу пользователя проверена документация NVIDIA и Microsoft (2026-10-14). В WSL CUDA использует драйвер Windows через предоставляемую `libcuda.so`; Linux-драйвер NVIDIA внутри WSL устанавливать нельзя. На отдельном Linux можно выбирать совместимые версии драйвера, CUDA Toolkit и ядра независимо от Windows. Это преимущество для диагностики и воспроизводимых замеров, но не доказанное ускорение нашей сети.
NVIDIA указывает ограничения WSL для полной Unified Memory, одновременного доступа CPU/GPU к managed memory и доступного объёма pinned memory. Собственный прототип использует явные копирования. Перенос STDP написан в `gpu_stdp.cu` и `gpu_stdp_bridge.cpp`, но сборка, проверка состояний относительно CPU и измерение ускорения ещё не выполнены. Эти файлы нельзя считать рабочим GPU-бэкендом.
Microsoft рекомендует для Linux-инструментов хранить рабочие файлы в файловой системе Linux, а не `/mnt/c`. Расчётные данные и сборки нашего стенда уже расположены в `/home/int`; исходники проекта остаются в `/mnt/c/KNP`.
Редактирование драйвера не требуется для реализации AltAI/STDP: отсутствие поддерживаемых типов нейронов и пластичности исправляется в KNP. Возможный выигрыш Linux следует проверять одинаковым прогоном на той же видеокарте. Переустановка ОС или драйверов не выполнялась.
Источники: [NVIDIA CUDA on WSL](https://docs.nvidia.com/cuda/wsl-user-guide/index.html), [Microsoft: файловые системы WSL](https://learn.microsoft.com/en-us/windows/wsl/filesystems).
## Рабочий быстрый режим
Для этой небольшой AltAI/STDP-сети быстрее запускать **несколько независимых однопоточных процессов KNP**, каждый со своим набором параметров, данными состояния и выходной папкой. `run_batch.py` запускает ограниченное число процессов, собирает ошибки и метрики, не перезаписывает существующие прогоны. Python-потоки здесь только управляют отдельными C++-процессами; вычисления не ограничены Python GIL.
`validate_v2.py` теперь использует этот запуск, по умолчанию 4 параллельных эксперимента. Пример следующего поиска с новым префиксом:
```bash
python3 /mnt/c/KNP/cats-dogs/validate_v2.py --jobs 4 --prefix next_val
```
Старые результаты выбора не перезаписываются. Новый поиск сохраняет `next_val-selection.json`, план и сводку в `/home/int/run/cats-dogs/acceleration`. Входы/данные остаются одинаковыми для сравнимых запусков. Один временной ряд внутри одной сети этим способом не разбивается между процессами.
## Измерение пропускной способности
Четыре **одинаковые** конфигурации новой validation: 4000 train + 1000 validation, 20 нейронов на класс, пороги 600/1600/4000/8000. Сначала измерена последовательная группа, затем та же группа с четырьмя независимыми процессами.
| Режим группы | Общее время |
| --- | ---: |
| Последовательно | 91,573 с |
| 4 процесса | 42,911 с |
Ускорение **2,134 раза**. Каждый отдельный параллельный прогон занял примерно 40,7–42,9 с вместо 22–24 с в одиночку, но вся группа закончилась раньше. Для каждого порога четыре CSV весов/порогов и `result.csv` совпали побайтно между последовательным и параллельным запусками. Выигрыш относится к группе независимых экспериментов, не к одной сети. Замер однократный; Windows/WSL и другие нагрузки могут менять время.
Результат: [acceleration-results/batch-benchmark.json](acceleration-results/batch-benchmark.json). Код измерения — `benchmark_batches.py`; повторный запуск требует новых имён, поскольку данные предыдущего замера защищены от перезаписи.
## Многопоточная обработка одной сети
В установленном KNP штатный `MultiThreadedCPUBackend::SupportedNeurons` содержал BLIFAT, STDP-BLIFAT и LIF, **но не AltAI**. Прямой запуск нашей сети завершался `Type is not supported`. Параметр количества потоков этого ограничения не исправляет.
Создана **отдельная** экспериментальная библиотека:
`/home/int/run/cats-dogs/acceleration/libknp-cpu-tuned-backend.so`
`build_tuned_cpu.py` копирует заголовок/реализацию многопоточного бэкенда в каталог эксперимента, добавляет `AltAILIF` и `SynapticResourceSTDPAltAILIFNeuron` к списку типов, использует существующие CPU-функции AltAI и STDP. Перекомпилируются **обе** единицы `backend.cpp` и `get_network.cpp`, чтобы их представления variant совпадали. Добавлены переменные фабрики:
- `KNP_CPU_THREADS`: по умолчанию 2.
- `KNP_CPU_POPULATION_PART`: по умолчанию 64.
- `KNP_CPU_PROJECTION_PART`: по умолчанию 8192.
Значения проверяются на корректность и границы. Штатные исходники и библиотеки KNP не заменялись. Патч для просмотра — [acceleration-results/cpu-altai-multithread.patch](acceleration-results/cpu-altai-multithread.patch).
```bash
python3 /mnt/c/KNP/cats-dogs/build_tuned_cpu.py
python3 /mnt/c/KNP/cats-dogs/run.py my_tuned_run \
--data-dir /home/int/run/cats-dogs/features-v2 \
--dataset sparse_hog_validation --train 4000 --count 1000 \
--quant weights --threshold 4000 --backend tuned --threads 2
```
На одинаковом коротком прогоне (800 train + 200 validation):
| Бэкенд | Время KNP train+inference | Веса и результат |
| --- | ---: | --- |
| Однопоточный | 4,89 с | эталон |
| Новый, 2 потока | 15,09 с | побайтно совпали |
| Новый, 4 потока | 15,69 с | побайтно совпали |
Поэтому `run.py` оставляет **однопоточный бэкенд по умолчанию**, а параллелизм для поиска организован между независимыми сетями. Наличие нескольких потоков само по себе не означает ускорения. В частности, в исходном многопоточном коде финализация STDP ставится в очередь одной задачей на популяцию, а у текущей сети одна небольшая обучаемая популяция; есть также барьеры между фазами каждого шага. Это кандидаты для дальнейшей оптимизации, не измеренная разбивка времени профилировщиком.
Короткий замер: [acceleration-results/backend-altai-benchmark.json](acceleration-results/backend-altai-benchmark.json). Полный валидационный прогон экспериментального бэкенда проверяется отдельно; результат будет добавлен после завершения.
## Видеокарта и CUDA
Стенд видит Intel i7-13700KF, 24 логических CPU в WSL, NVIDIA RTX 4070 Ti SUPER (compute capability 8.9, около 16 ГБ VRAM). Драйвер, сообщённый `nvidia-smi`: 610.88; установленный CUDA Toolkit: 12.9. Эти значения не следует смешивать с максимальной версией CUDA API, показанной драйвером.
Базовое CUDA-ядро `/home/int/scratch-cu/t2` успешно записало и прочитало число 42: `no error h=42`. Это подтверждает работу базовых CUDA-вычислений в WSL, не всего GPU-бэкенда KNP.
В установленном исходнике `gpu-cuda/backend.h`:
```cpp
using SupportedNeurons = boost::mp11::mp_list<knp::neuron_traits::BLIFATNeuron>;
using SupportedSynapses = boost::mp11::mp_list<knp::synapse_traits::DeltaSynapse>;
bool plasticity_supported() const override { return false; }
```
Следовательно, **GPU-бэкенд не умеет нашу модель AltAI и не выполняет STDP-обучение**. Исправление архитектуры компиляции не добавляет эти функции. Бинарник уже содержит `sm_89` cubin, что проверено `cuobjdump`.
Кроме отсутствия модели, простой BLIFAT-пример через GPU-бэкенд воспроизвёл `invalid device function` в коде CUDA-векторов KNP. Лог — [acceleration-results/cuda-knp-probe.log](acceleration-results/cuda-knp-probe.log). Пример при этом может завершиться с кодом 0, поскольку ошибки только журналируются; это не успешное выполнение сети. Причина этой ошибки не установлена и не исправлена.
Чтобы обучать именно эту AltAI/STDP-сеть на GPU, нужны реализация её состояния, правил пластичности и обмена сообщениями в CUDA и проверка против CPU. Это отдельная доработка бэкенда; **GPU-обучение в этой работе не включено**. Текущий доступный выигрыш — проверенный параллельный поиск на CPU. Переход на другую модель нейрона или другое обучение должен оформляться как отдельный эксперимент.