# 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. Переход на другую модель нейрона или другое обучение должен оформляться как отдельный эксперимент.