Привет! Столкнулся с интересной ситуацией, которая хорошо иллюстрирует важность внимательного чтения документации.

❌ Проблемный код
У меня был std::list<std::unique_ptr<Item>>, и я хотел переместить завершённые элементы в другой список. Написал, казалось бы, логичный код:

auto it =  std::remove_if(active.begin(), active.end(), [](auto& item) {
  if (item->is_completed()) {
    item->reset();
    return true;
  }
  return false;
});

// Перенос в другой список
stopped_submits_.splice(stopped.begin(), active,  it, active.end());

И... неожиданно обнаружил нулевые указатели в списке!

🔍 Что пошло не так?

Ошибка №1: Нарушение контракта предиката
Сигнатура std::remove_if требует, чтобы предикат не модифицировал элементы:

template< class ForwardIt, class UnaryPred >
ForwardIt remove_if(ForwardIt first, ForwardIt last, UnaryPred p );

Из документации:
>The expression p(v) must be convertible to bool for every argument v of type (possibly const) VT, where VT is the value type of ForwardIt, regardless of value category, and must not modify v.

Мой item.reset() явно нарушает это требование.

Ошибка №2: Неопределённое состояние после remove_if
После работы std::remove_if элементы в диапазоне [result, last) могут находятся в неопределённом состоянии. Для std::unique_ptr это означает, что они могут стать нулевыми в результате перемещения!

Из документации:
> Each element of [result, last) has a valid but unspecified state, because move assignment can eliminate elements by moving from elements that were originally in that range.

📚 Выводы
1. Используйте std::remove/remove_if в рамках идиомы remove-erase
3. Читайте документацию и стандарт, в частности cppreference

#cpp #stl #cplusplus #bugs

Привет, немного информации о проекте про разработку которого я рассказываю в этом канале:

Adept(Automatic Differentiation Engine for Tensor Processing) — это библиотека на Python и C++ для построения и обучения нейросетей, созданная с упором на кроссплатформенность, гибкость и образовательную ценность.

⚙️ Основные возможности:
• Динамические графы — как в PyTorch: отладка, условия, циклы «из коробки».
• Тензоры + Autograd — автоматическое дифференцирование и GPU-ускорение.
• Vulkan backend — работает на GPU от NVIDIA, AMD, Intel, Qualcomm и даже на мобильных устройствах.
• Единая семантика Python/C++ — легко переносить прототип в production.

🎯 Зачем это нужно?
В российской экосистеме почти нет open-source ML-платформ общего назначения, сравнимых с PyTorch или TensorFlow. Возможно это связано как с нехваткой специалистов, сочетающих глубокое понимание машинного обучения и системного программирования, так и доступностью зрелых альтернатив. Adept создан как экспериментальная площадка для накопления такого опыта — как исследовательского, так и образовательного.

🧠 Почему это полезно для обучения?
Проект охватывает все ключевые уровни ML-стека: от математических абстракций (тензоры, градиенты) до низкоуровневой работы с GPU. Это делает его подходящей основой для:
• Изучения архитектуры современных ML-фреймворков
• Курсовых, дипломных и исследовательских работ
• Практических заданий по deep learning, системному программированию и кроссплатформенной разработке

🔗 Код открыт — приглашаем студентов, преподавателей, энтузиастов и всех, кто хочет разобраться, как устроены ML-платформы изнутри.

#MachineLearning #OpenSource #Education #Vulkan #Python #Cpp #Adept #MLPlatform

Привет, сделал декомпозицию задач про ускорение свёрточных операций — сердце современных CNN:

• https://gitverse.ru/kolkir/adept/tasktracker/TSKDPT3-90
• https://gitverse.ru/kolkir/adept/tasktracker/TSKDPT3-79

Есть три основных задачи:

🔥 Быстрые свёртки для инференса (CPU/GPU)
Цель: Максимально ускорить вывод моделей за счёт оптимизированных алгоритмов свёрток.
Что делать:
Исследовать подходы (включая Winograd и альтернативы)
Учесть ограничения: поддержка batch, channels, padding
Реализовать ядра:
• CPU — через SIMD-библиотеку Highway
• GPU — через compute-шейдеры Vulkan
Сравнить результат с текущим im2col
💡 Идеально, если хочешь разобраться в алгоритмах свёрток и хочешь «выжать» максимум из железа.

⚙️ Умная диспетчеризация режимов
Цель: Автоматически выбирать алгоритм в зависимости от сценария.
Логика:
Инференс: быстрые свёртки для ядер 3×3–7×7 → иначе im2col
Тренировка: всегда im2col (работа с большими матрицами)
🎥 Как устроена наша диспетчеризация

🚀 Implicit GEMM для тренировки
Цель: Ускорить обучение за счёт сокращения аллокаций памяти.
Почему это круто:
Минимум промежуточных буферов
Эффективный тайлинг — строим только нужный фрагмент матрицы свёртки «на лету»
Лучшее распараллеливание → выше производительность на тренировке
Этапы: дизайн → реализация (CPU/GPU) → бенчмарки против im2col → замена при профите.

👉 Готов браться? Читай правила участия, пиши— обсудим детали и подберём задачу под твои скиллы!

#opensource #machinelearning #optimization #vulkan #simd #cpp

🚀 Небольшие оптимизации в adept: Linear layer и sum()

Привет! Наконец-то после 3х недель написания документации в виде статей удалось вернуться к разработке. Сделал ряд улучшений в библиотеке, которые немного улучшили производительность операций обратного распространения градиента.

1. Обобщённая операция sum(dim)

Раньше операция суммирования работала только для всего тензора или только по первой оси (sum_dim0). И по оси была наивная реализация которая в цикле суммировала все значения по 0му измерению, что приводило к существенным задержкам при большом пакете. Теперь:

- sum(dim) — суммирование по любой оси
- Поддержка отрицательных индексов
- Оптимизированные шейдеры для на основе subgroups
- Работает с тензорами до 4D включительно

2. Небольшая оптимизация Linear layer backward

В обратном проходе линейного слоя убрал одно матричное транспонирование. Что сокращает количество операций с памятью и немного ускоряет расчёт градиентов.

3. Тестирование через naive implementation

Добавлена эталонная реализация линейного слоя для валидации точности вычислений в тестах. Это гарантирует, что оптимизации не влияют на корректность вычислений.

Что дальше?

Есть задел для дальнейшего ускорения (~10%) — реализация поддержки смещений(strides) в тензоре. Это позволит избежать реальных транспонирований матриц в некоторых случаях, работая с данными “на лету”. Дальнейшие оптимизации matmul должны уже наверное использовать специальные матричные расширения, например Tensor Cores в NVIDIA.

Реализация смещений в тензоре для работы с памятью также позволит реализовать функциональность срезов(slices). Что откроет возможность для импортирования уже реальных моделей, например YOLO.

#adept #deeplearning #performance #vulkan #cpp

Привет, я делал доклад на тему «Эмуляция запуска GPU-ядер на CPU или нестандартные приёмы отладки». Выкладываю презентацию, в которой рассказываю про реализацию симулятора, воспроизводящего модель выполнения GPU (Grid → Block → Thread) с полной интеграцией в GDB.

В отличие от CUDA, где есть много иструментов для отладки и анализа, экосистема Vulkan и OpenCL практически лишена инструментов пошаговой отладки общего назначения. Презентация показывает трюки, позволяющие разрабатывать и отлаживать ядра без физического ускорителя.

Ключевые архитектурные решения:
• Lockstep-исполнение на корутинах (C++23): Каждый поток реализуется через std::generator. Вызов co_yield эмулирует аппаратный барьер, а внешний диспетчер синхронно продвигает все генераторы, обеспечивая детерминированное блокирующее выполнение, идентичное __syncthreads().
• Иерархия контекста и памяти: Контекст инкапсулирует координаты потоков и размеры сетки/блока. Выделяются именованные области разделяемой памяти с семантикой, повторяющей shared, для кооперативной работы потоков внутри блока.
• Трекер доступа к памяти: Прокси-обёртка над буферами логирует каждое чтение/запись с привязкой к координатам потока. Постобработка группирует доступы, проверяет последовательность адресов для соседних потоков и рассчитывает метрику эффективности группировки и распределение шагов (strides).
• GDB Python-инфраструктура: Кастомные pretty-printers и специализированные команды позволяют инспектировать состояния блоков, разделяемую память и визуализировать линейные буферы как 2D-матрицы прямо в сеансе отладки.

Презентация
Код проекта

#VulkanCompute #Cpp #Coroutines #GDB #GPUDebugging #SIMT

Привет! В очередной раз решил сделать Docker образ с Vulkan-бэкендом для сборки проекта. Дело в том что публичные образы (например, localai/localai:latest-gpu-vulkan или j3soon/vulkan-runtime) устарели: в них либо старая версия SDK, либо отсутствует актуальный toolchain (CMake, Python, Node.js), либо нет актуальной поддержки X11/Wayland. Использовать их без существенных доработок не получилось, из-за чего я переключил CI сборку чисто на хост систему. И в последних PR мы получили проблемы с использованием различных сред разработки.

Решение: собственный многостадийный Dockerfile.

- Base toolchain — устанавливается всё для компиляции и линтинга (clang, ccache, doxygen, Python 3.11, Node.js 20 LTS). Без Vulkan.

- Vulkan SDK — загружается и настраивается конкретная версия SDK (1.4.341.0) с runtime-зависимостями.

- Финальный образ, куда копируются только нужные артефакты от предыдущих стадий. Это сокращает размер образа и исключает «мусор» из промежуточных слоёв.

Как используем:

В VS Code DevContainer — в devcontainer.json пробрасываются GPU (--gpus all, /dev/dri), X11 и сеть хоста. Разработчик работает в изолированной среде, идентичной CI.

В CI (self-hosted) — в YAML-описании указывается предварительно собранный образ (экономим время на установке зависимостей при каждом запуске) и те же флаги рантайма: --gpus all, --device=/dev/dri, --network=host. Это гарантирует, что Vulkan-тесты реально выполнятся на GPU.

Результат: воспроизводимые сборки, отсутствие «у меня работает» на машине разработчика, а CI ловит проблемы со средой сборки на начальных этапах.

Рекомендую использовать контейнеризацию для разработки всегда когда это возможно, хотя с GPU это бывает непросто.

#Docker #Vulkan #CI #DevOps #Cpp #DevContainer