Когда современные нейросетевые модели с INT8-квантованием начинают выполняться за единицы миллисекунд, «узкое место» системы смещается с чистой вычислительной мощности на инфраструктуру вычислительного конвейера и операции ввода-вывода. При использовании дискретных графических процессоров многократная передача видеокадров высокого разрешения и промежуточных данных, таких как, например, bounding boxes (для случая object detection), по шине PCIe способна существенно снизить общую пропускную способность.

Архитектура Zero-Host-Copy заключается в том, чтобы начиная с чтения с диска перед декодированием и заканчивая записью на диск после финального кодирования, файлы кадров оставались в памяти GPU и обрабатывались только с помощью GPU, а копирования данных GPU -> CPU и обратно минимизировались. Если же говорить про Zero-Copy архитектуру, то под ней подразумевается передача блоков данных для обработки от одного этапа конвейера к другому исключительно по указателю без излишнего копирования данных.

Впрочем, лишние копирования CPU-GPU — не единственный скрытый фактор, снижающий эффективность конвейера. Динамическое выделение памяти в процессе работы системы столь же пагубно сказывается на быстродействии в реальном времени. Это происходит в связи с тем, что вызов cudaMalloc влечет за собой неявную синхронизацию (implicit synchronization), заставляя CPU ждать GPU, что нарушает асинхронность конвейера. Для достижения максимальной частоты кадров (FPS) высокопроизводительная система должна строиться с учетом реализации трех фаз жизненного цикла: «фаза инициализации» (initialization phase), «фаза подготовки» (warm-up phase) и «фаза активной работы» (hot phase). На этапе инициализации приложение заранее выделяет необходимые пулы памяти, буферы и очереди с начальными параметрами вложенности (глубины). В процессе фазы подготовки система запускает полную очередь обработки, где возможно срабатывание механизмов выделения дополнительных буферов в соответствии с реальной работой. Как только конвейер переходит в фазу активной работы после прогона нескольких начальных кадров, динамическое выделение памяти должно быть полностью исключено. Такая архитектура не допускает вызовов cudaMalloc или new во время выполнения, полагаясь исключительно на повторное использование уже выделенных блоков памяти для поддержания стабильной частоты (FPS).

В статье - реализация bare-metal конвейера без DeepStream: обработка видео с YOLOv8m (1024x1024-INT8) на ~165–215 FPS (RTX 3060 Ti) и ~38 FPS (Jetson Orin Nano Super).

GPIO-линии - это базовая периферия любого микроконтроллера и первое с чего начинают знакомство с новым МК. Чего может быть проще помигать светодиодом. Библиотеки производителей МК, также как и сторонние, обычно предоставляют функции записи одной линии типа HAL_GPIO_WritePin, digitalWrite, либо же запись всего порта. А часто требуется управлять сразу группой разрозненных GPIO-линий: светодиодная лента, 7-сегментный индикатор, параллельная шина данных, матричная клавиатура и т.д.

С конфигурированием GPIO-линий дела обстоят не лучше, нужно заполнять поля неудобных структур в HAL-подобных библиотеках, и часто конфигурирование по одному пину - громоздко, неудобно, много однообразного copy-paste кода.

В этой статье представлен новый метод работы с GPIO для микроконтроллеров, который сочетает возможность динамического создания групп GPIO линий и хорошую оптимизацию для групп заданных на этапе компиляции, на примере Российского МК К1921ВГ015.

Я убрал из своего решения 60% работы, а программа стала медленнее. На Эльбрусе такое бывает чаще, чем кажется: параллельность здесь заранее расписывает компилятор, и «хитрый» код с проверками и прыжками по памяти проигрывает простому, но ровному циклу.

Этой осенью я выиграл Кубок СЭРПАС 2026, соревнование по оптимизации программ на C/C++ под процессоры Эльбрус, и в трёх статьях рассказываю, как решал задачи и что на e2k работает не так, как на x86. В первой части: чем Эльбрус отличается от привычных процессоров, как я мерил скорость и как считать 32 пары строк за один проход.

Я решил проанализировать реальные примеры, вот например

https://github.com/openbmc/dbus-sensors/blob/ce706f061f2b6877e953fa0ad8f5200e99f15854/src/VariantVisitors.hpp#L53. и посмотреть на сколько код с эксепшенами лучше или хуже некоторой альтернативной версии кода. Заодно посмотрим есть ли альтернатива коду с эксепшенами.

Многие из нас писали асинхронный код, который помогает не блокировать потоки при ожидании ответа от процессов, сетевого соединения или устройств. Вызов с callback-функцией задействует много сущностей: и планировщик задач, и межпроцессное взаимодействие, и системные вызовы, и механизмы ядра Linux. Без асинхронных вызовов не обходятся настольные операционные системы, и их разработка требует баланса между производительностью и безопасностью. Также важно сохранить код читаемым и удобным. 

Меня зовут Илья Клементьев. Я разрабатываю настольную операционную систему kvadraOS Desktop на основе ChromiumOS. В этой статье я постараюсь найти ответ на вопрос: что же все-таки лучше для асинхронного кода — poll() или epoll()? И нужно ли это оборачивать в корутины C++20? 

Браузеры традиционно относятся к самым крупным потребителям памяти на персональных компьютерах. Иногда кажется, что разработчики просто забили на оптимизацию, но реальность куда прозаичнее: пользователи открывают всё больше вкладок, сайты обрастают медиа и JavaScript, новые веб‑стандарты требуют хранить больше данных, а ради безопасности браузер изолирует сайты в отдельных процессах.

На три последних пункта повлиять сложно. Но что делать с десятками вкладок, которые пользователь открыл, посмотрел и забыл? Не запускать процесс до первого посещения — легко. Гораздо интереснее случай, когда страница уже загрузилась и продолжает занимать память — почти как активная вкладка.

Просто так закрыть её нельзя: страница потеряет состояние, а музыка, видео или фоновая задача могут прерваться. В Chromium уже есть сборка мусора, очистка кешей и другие способы оптимизации — однако память всё равно не всегда возвращается операционной системе надолго.

Чтобы разобраться, почему так происходит, мы в команде Яндекс Браузера собрали собственный профайлер обращений к страницам памяти. Под катом — устройство виртуальной памяти, lock‑free‑структуры внутри обработчика сигнала, профилирование через управляемый SIGSEGV, борьба с kevent64, mach_msg и libdispatch, а также переход от эксперимента на macOS к оптимизации, которая сильнее всего проявила себя на Windows.

Данная статья представляет собой анализ официальных документов и статистических данных. В ней рассматриваются причины выбора(организаций) в пользу Rust, технические механизмы (такие как система владения и семантика перемещения), обеспечивающие безопасность без потери производительности, а также объективные ограничения и издержки, с которыми сталкиваются компании при миграции. Отдельное внимание уделено ответным мерам со стороны сообщества C++ и прогнозам развития индустрии.

Привет, Хабр! Меня зовут Алексей Макареня, я старший разработчик в «Лаборатории Касперского». Наша команда занимается централизованной системой контроля версий, и это тот самый поезд из заголовка. Через сервер этой системы идет работа с монорепозиторием, где лежит код десятков продуктов, поэтому остановить его на ремонт нельзя.

Сервер годами жил на акторах и дожил до того, что перед мелкой правкой разработчик по нескольку часов восстанавливал в голове поток управления. Под катом рассказываю, как я за восемь месяцев перевел его на корутины C++20 прямо на ходу, зачем для этого понадобилась собственная библиотека на 387 строк и почему иногда полезно сначала написать функцию на 565 строк.

Думаю, вы знаете, что C++ — язык, который разрешает вам вообще всё. А потом молча смотрит, как вы на этом подрываетесь. Обычно мы привыкли мыслить категориями байтов, но что делать, если стандартная сетка типов кажется слишком расточительной? Когда внутренний перфекционист требует компактности, на помощь приходят битовые поля. Зачем отдавать под скромный флаг “да/нет” целый восьмибитный контейнер, если можно ювелирно отрезать ровно один бит? Поставил двоеточие — и ты повелитель памяти. Но там, где начинается экономия, заканчивается порядок и предсказуемость. Программист остается один на один с тонкостями стандартов и поведением конкретных платформ. Предлагаю вместе заглянуть под капот C++ и подробно разобрать, как на самом деле устроены битовые поля.

Рабочая переписка редко хранится в одном месте. Документы приходят по почте, детали обсуждаются в чате, встречи планируются в календаре. Длинную цепочку писем удобнее читать за компьютером, а расписание в календаре можно посмотреть и с телефона.

Мы небольшой командой разрабатываем клиентское приложение CommuniGate Pro, объединяющее почту, календарь, контакты и чаты. Оно работает на Windows, Linux, macOS, Android и iOS. Пишем на Dart и Flutter, поэтому большая часть кода у нас общая для всех платформ.

Это упрощает разработку и поддержку приложения и интерфейса, но возможности десктопной и мобильной версий все же различаются. Например, локальные почтовые архивы мы сделали только для десктопа. Этой задачей я как раз и занимался. Идея простая: пользователь переносит старые письма с сервера на компьютер, освобождает место в почтовом ящике и продолжает работать с письмами прямо в приложении.

В этой статье я расскажу, как встроил локальные архивы в общий проект, как проверял их на больших объёмах и как попутно реализовал ещё одну возможность - общий буфер длительных операций.

Представим простую задачу: десять потоков должны увеличить общий счётчик по миллиону раз. Математика элементарная — в результате ожидаем десять миллионов.

Но программа может вывести совсем другое число. Причём ошибка не обязательно будет повторяться при каждом запуске.

Разберёмся, почему так происходит, как исправить проблему с помощью std::mutex и std::atomic, когда нужны std::condition_variable и std::future, а также чем std::jthread удобнее обычного std::thread.

Все примеры рассчитаны на C++20, если не указано иное.

Недавно я прочел статью про pyrusmorph — python обёртку над 30-летним с++ ядром libmorph/rus. Бенчмарки удивили: в 30 раз быстрее PyMorphy3 при обработке текста. После я задумался. Как это вообще работает? Почему мы пишем import pyrusmorph и получаем доступ к нативному с++ коду и функциям прямо внутри python.

В статье я предлагаю пройти этот путь с нуля. Разобраться, как устроен Python «под капотом», написать своё расширение на чистом C‑API, а потом посмотреть, как эту боль лечит pybind11. В конце — бенчмарки и практические советы, когда вообще стоит лезть в c++ для оптимизации. Бонус — немного о компиляторе python кода (JIT‑компилятор)

Привет, Хабр!

Спор «Rust или C++» идёт с 2015 года, с выхода Rust 1.0, и за одиннадцать лет превратился в отдельный жанр со своими приколами. «В Rust на каждом индексе проверка, вот он и тормозит». «В плюсах проверок нет, значит, быстрее». «Ага, а у Rust ссылки не пересекаются, так что быстрее как раз он». «Паника дорогая», «исключения дорогие», «абстракции бесплатные». Каждая сторона уверена в своём, а в ассемблер почти никто не смотрит, хотя ответ лежит прямо там (и местами он неприятный для обеих сторон).

В одну статью вопрос «круче ли Rust, чем C++» не влез, так что это первая часть, и она про скорость. Безопасность и прочие поводы поругаться ждут своей очереди.

Когда у тебя слабый ноутбук, офисная машина или телефон, на котором открыта пара тяжелых приложений, лишние 300 МБ под один только VPN начинают ощутимо бить по системе. А если речь идет об iOS, где системный лимит на сетевые расширения (PacketTunnelProvider) составляет жесткие 50 МБ, такие клиенты регулярно падают по OOM (Out Of Memory) при попытке загрузить крупные гео‑базы.

В один прекрасный день мне это надоело. Я решил взять всё в свои руки и написал с нуля собственный кроссплатформенный TUN‑клиент и сетевое ядро на чистом Rust без единой сторонней прослойки. Встречайте — Unbihex (названный в честь гипотетического 126-го элемента унбигексия). Сейчас он потребляет 18 МБ ОЗУ в режиме TUN (и 12 МБ в прокси), поддерживает полный стек современных протоколов и уже готов к продакшену.

Под катом — как это устроено под капотом, какие грабли пришлось собрать при работе с TUN под Windows и как удалось подружить ядро с популярными панелями.

Привет, Хабр!

Это вторая статья цикла про C++. В первой я разбирал базу для тех, кто начинает с нуля: переменные, циклы, классы, контейнеры. Здесь идём на уровень ниже — как обычная C+±программа договаривается с операционной системой.

Сразу скажу, зачем я вообще полез в эту тему. В колледже была лаба, где нужно было поднять процесс, дождаться его и снять код возврата. Я неделю не понимал, почему fork() в одном случае возвращает ноль, а в другом — PID, и почему после exec ребёнок «исчезает». Препод объяснил это минут за десять — и я понял, что половину объяснений всё равно не понял. С тех пор я пишу такие вещи с расстановкой: не «fork() создаёт процесс», а что именно он возвращает, что происходит в коде после вызова и что будет, если забыть закрыть дескрипторы. Поэтому статей будет много, а примеров в каждой — ещё больше.

Что дальше в цикле, чтобы было понятно, куда мы движемся:

Рассказываю про Тулпар (Тұлпар) — язык программирования с казахскими ключевыми словами и синтаксисом в стиле Python, который компилируется в нативный код x86-64. Компилятор и рантайм написаны на Rust с нуля: без LLVM и без libc, с собственным аллокатором регистров и сборщиком мусора. Разбираю конвейер компиляции, устройство GC, замеры против C, Rust и Python, а также то, чего в языке пока нет.

Наступила эпоха, когда любая домохозяйка за несколько промптов поднимает себе CRM: фронтенд на JS, бэкенд на Go, данные в Postgres. И при этом не понимает ни слова из того, что я сейчас написал.

А куда заведёт кривая гика, который пятнадцать лет отдал коммерческой разработке ещё в доLLMную эпоху?

Дело было вечером, подписка на Claude Code простаивала, мысли вертелись. Перебирая прожитые годы, я вспомнил детскую мечту: написать свою операционную систему. Хорошую, чтобы всех радовала и приносила людям пользу. Как Windows, только лучше.

Windows из списка хороших систем я вычеркнул ещё в школе, вместе с синим экраном. Да и Linux перестал казаться идеалом, когда я начал считать микросекунды.

Отдельная линия этой истории: я делал всё это в паре с Claude Code. И где-то к середине проекта поймал себя на забавной мысли — Claude Code, по сути, собирал своего же младшего брата: маленького Claude, который теперь живёт внутри колонки и откликается на «Клод». Старший пишет код, отлаживает, диагностирует — чтобы младший поселился в железке и заговорил. Дальше эта мысль меня уже не отпускала.

В этой статье я расскажу, как устроена звуковая подсистема Nintendo Gameboy, с какими проблемами я столкнулся, пытаясь в реальном времени генерировать звук и синхронизировать с ним картинку. Статья является продолжением моей прошлой публикации.

Разбираем производительность морфологических анализаторов для русскоязычных текстов в Python-среде. Расскажем, почему библиотеки семейства PyMorphy работают так медленно и как интеграция нативного C++ ядра libmorph/rus решает проблему производительности high-load систем.

Всем привет! Я продолжаю развивать свою библиотеку для создания распределённых приложений. Она уже легла в основу новой версии rats-search (распределённый торрент-поисковик) и rasync (синхронизация папок, файлов и исходников между устройствами) и ratcast (распределенный видео-аудио стриминг и приложение наподобие Discord для совместного просмотра фильмов и видео-конференций с более высоким качеством и большим количеством участников и сложной p2p+MCU топологией), а также librats, судя по всему, используется в стороннем клиенте UltraVNC (VNC-клиент).

Библиотека позволяет развернуть собственную P2P-сеть, связать пользователей между собой и выстроить обмен данными через потоки разных типов — бинарные, строковые и другие. Главная особенность — автоматическое обнаружение участников (peer discovery) на основе mDNS и DHT Mainline протоколов без необходимости в серверах, что особенно актуально в условиях постоянных блокировок и сетевых ограничений. Общения происходит напрямую - без посредника.

На данный момент поддерживаются C/C++, Java (Android), Python и Node.js.

В этом обновлении значительно улучшен собственный QUIC-подобный протокол поверх UDP: добавлена поддержка app-limited-режима, управление перегрузкой переведено на BBRv3, реализована полноценная прямая коррекция ошибок (FEC), улучшен обход NAT, а также появился модуль rendezvous для развёртывания вспомогательных серверов, повышающих связность сетей.

Последний стабильный релиз на сегодня — 3.0.3. Исходный код и собранные бинарные файлы доступны для:

journald умеет почти всё, что нужно для разбора проблемы на сервере: индексирует поля, фильтрует по юниту, процессу, пользователю и загрузке, ищет по времени и отдаёт записи по курсору. А смотрим мы его через journalctl, то есть одной командой за раз. Эта статья — о том, как оконный интерфейс из 1990 года оказался почти идеальной формой для этих возможностей, и о том, как устроен получившийся просмотрщик TurboJedi.

Каждый разработчик на C++ начинает свой путь с оператора new. Нам объясняют его работу очень просто: «new выделяет память в куче и создает там объект». Мы пишем auto ptr = new MyClass(42); и до поры до времени не задумываемся, что скрывается за этой строчкой.

Здравствуйте, друзья, меня зовут Ерохин Кирилл, я популяризатор российского программного и аппаратного обеспечения, и в этом сентябре я провёл уже второе, теперь ежегодное, соревнование по алгоритмическому программированию на отечественных аппаратных платформах «Кубок СЭРПАС 2026», собрав 112 участников со всей России, результатами которого пришлось поделиться с вами. А Хабр мне в этом поможет, ему не впервой.

Привет, Хабр! Меня зовут mixitosik, я разрабатываю открытый язык программирования общего назначения RayQuiro.

Когда берешься за создание собственного языка, большинство гайдов и туториалов быстро упираются в тупик: они учат писать либо «игрушечные» древовидные интерпретаторы (Tree-walk AST), либо простые трансляторы в C. На практике же любой язык общего назначения требует решения жестких системных задач: проектирования компонуемой модульной системы, многоуровневого пайплайна исполнения (для мгновенных итераций и для продакшена), кроссплатформенного рантайма и интеграции легковесного GUI без раздувания зависимостей до размеров Electron.

В этой статье я по шагам разберу внутреннее устройство RayQuiro: структуру парсера и AST, архитектуру стековой виртуальной машины, генерацию IR для LLVM-бэкенда, а также инженерные грабли, на которые пришлось наступить при реализации динамического языка со строгим управлением памятью.

Это моя первая статья подобного рода(да и в целом любого рода), в которой я покажу как писал keygen для простенького приложения. Я использовал динамический анализ через x96 dbg, плюсы для keygen'а, и, конечно же, родненький ассемблер. Статья предназначена для новичков в реверсе и всех, кто хочет что‑то вспомнить. Если зайдет — это может превратиться в серию статей с повышающимся уровнем сложности реверса, но это в мечтах, а пока к сути.

Привет, Хабр!

В первой части я рассказал про железо, сборку корпуса и немного затронул программную реализацию. Сегодня — самое вкусное. Мы заглянем в исходники проекта и разберем математику, алгоритмы и оптимизацию под слабое железо.

Код написан на C++ в Arduino IDE, весь проект живет в одном файле. У нас три игры

(но в исходнике их уже пять), которые переключаются конечным автоматом через gameState.

Блок 1: Raycast — 3D на коленке

Сердце движка — DDA-алгоритм (Digital Differential Analyzer). Мы не рендерим 3D-полигоны, мы пускаем 320 лучей из точки игрока и смотрим, где они пересекают сетку 32x32.

UDP ничего не обещает: датаграмма может не дойти, прийти дважды или обогнать соседнюю. Обычно в ответ берут TCP или пишут свой протокол с повторными запросами. Оба пути платят за потерю как минимум одним round trip, и платят именно тогда, когда сеть и так перегружена. В статье разобран другой вариант: отправитель заранее добавляет в поток избыточные пакеты, и получатель восстанавливает потерянное сам, ни о чём не спрашивая. Это прямая коррекция ошибок (FEC, forward error correction) кодом Рида — Соломона.

Казалось бы, в чём связь между графикой и звуком?

Продолжая тему расчёта цифровых фильтров, постараемся дать ответ на этот вопрос.

Разработка графического движка на Vulkan API требует параллельного выполнения задач: сборки командных буферов, стриминга ресурсов и генерации кадров.

В этой статье описана архитектура библиотеки shuttle_async, написанной на бесстековых корутинах C++23. Ниже подробно разобрано устройство многопоточного планировщика Work Stealing на деках Chase-Lev, механизм снижения избыточных пробуждений потоков (Coalesced Wake-ups), а также логика работы Immediate-режима запуска, миграция контекста в котором может приводить к нарушению инвариантов Structured Concurrency.

Это фрагмент множество Мандельброта и я его описал в википедии:
https://commons.wikimedia.org/wiki/File:Mandelbrot_Set_Image_118.png

А вот скажите... Кажется ли вам что объемная картина? Выпуклая? Особенно синий! А почему? Это же очень интересно! Говорят что да. Это мощный оптический эффект трехмерности на плоском рисунке. Наш мозг, привыкший считывать распределение света и тени в реальном мире, мгновенно интерпретирует эти плавные градиенты как трехмерный рельеф, хотя на самом деле мы смотрим на абсолютно плоскую двухмерную проекцию.

Строгая типизация в HurriCache — осознанный выбор. Мы явно создаём скаляры (целые числа, числа с плавающей точкой, байтовые массивы) и контейнеры (List, Vector, Queue, OrderedSet, HashSet, SortedMap, HashMap) без ленивого приведения типов. Это даёт предсказуемость поведения и контроль над памятью, но повышает порог входа: нельзя просто взять и «подставить» HurriCache вместо Redis, не меняя семантику работы с данными.

Чтобы решить эту проблему, мы добавили RESP‑коннектор, совместимый с Redis‑клиентами. И сразу столкнулись с фундаментальными различиями моделей данных: то, что в Redis «просто строка», в HurriCache требует явного типа и стратегии создания.

Утро у меня начиналось с вкладки трекера, вкладки календаря, заметок и пары PR, и полгода назад я начал делать себе десктопное приложение, которое собирает это в одно окно с клавиатуры. Ниже — что внутри и где я по дороге наступил на грабли: 13 трекеров через один дескриптор, все данные в одном JSON с миграциями и машиной времени, Vim‑клавиши по физическому месту клавиши и задача, которую подсказывает git‑ветка. Называется Tabless, код открыт под MIT.

На производстве код «Честного знака» читает камера над лентой, и символ на кадре мелкий — 2–3 пикселя на модуль, повёрнутый, смазанный, на изогнутом боку бутылки. Мы сравнили, как с такими кадрами справляются ZXing, zxing-cpp, libdmtx и наша библиотека dmr. Кадры, ожидаемые строки и скрипты замера выложены — любую цифру можно проверить.

Коротко: — на 1368 синтетических кадрах dmr прочитал 82 %, zxing-cpp — 70 %, libdmtx — 65 %, ZXing (Java) — 3 %; — ложных чтений — ноль у всех четырёх библиотек; — dmr надёжно читает от 1,4 пикселя на модуль и при любом угле поворота; — zxing-cpp примерно в 2,5 раза быстрее; — есть условия, где соперники читают больше dmr, — разбираем их в статье.

Статья посвящена системному программированию на русском языке с C-подобным синтаксисом. Компилятор для языков программирования РУСИ, РУСИ++ и объектный-РУСИ создан путём модификации и пересборки компилятора GCC 14й версии с превращением его в полноценный русско-английский билингвальный компилятор. Отдельно дана инструкция модификации русской раскладки клавиатуры для добавления в неё фигурных, угловых и квадратных скобок - дабы не переключаться и не терять поток.

Shared memory в ROS 2 это буквально чит-код на бесплатное ускорение? Одна строка в конфиге, и мегабайтные сообщения летят через общую память, а не через сеть, но ros2 node list показывает пустой список, хотя всё работает. Разбираемся в нюансах и фичах механизмов shm и zero-copy на примере ROS2 Humble + CycloneDDS.

Классические MMORPG золотой эпохи (в частности, стек World of Warcraft времен Wrath of the Lich King) архитектурно строились вокруг так называемой «святой троицы»: танк, целитель, бойцы урона. Вся математика подземелий — тайминги способностей боссов, механики переагривания, периодический урон (DoT), дебаффы и энкаунтеры — изначально рассчитывалась на плотное разделение ролей между 5, 10 или 25 участниками.

Однако демография игроков за 15 лет кардинально изменилась: порог входа по свободному времени вырос, а потребность в исследовании старого контента осталась. В сообществе эмуляторов (TrinityCore, AzerothCore и кастомных форков) сформировалось целое направление — Solocraft.

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

У меня геймпад Flydigi Vader 5 Pro и к нему док-станция Charging Dock 2 Pro. На доке 162 RGB-светодиода, и сами по себе они хорошие, а вот эффекты из фирменной Space Station выглядят дёшево: медленные анимации идут ступеньками, градиенты грязнеют в середине.

Стало интересно, виновато железо или софт. Спойлер: софт. Разобрал, как док принимает кадры, переписал эффекты с нуля и сделал свой редактор подсветки.

Недавно я обнаружил что LLM агенты уже могут реализовывать довольно сложные задачи самостоятельно с неплохим качеством кода.

И тут я понял - чего бы не попробовать сделать своё расширение для clang с корутинами, которые гарантированно не используют аллокации и поверх этого реализовать небольшую операционную систему на корутинах для микроконтроллера.

Что, если я скажу, что на 8-битном микроконтроллере AVR можно запустить честный секторный 3D‑движок? Не рейкастер, не вращающийся куб, а настоящий Build Engine в духе Duke Nukem 3D — с порталами, секторами и перепадами высот?

Все знают, что Джон Кармак в 1993 году сделал DOOM. Гораздо меньше людей знают, что Кен Сильверман тогда же пытался разобраться в BSP‑деревьях Кармака, не понял их — и изобрёл свой движок. На нём потом взлетел Duke Nukem 3D. Я пошёл по его стопам — только вместо ПК — AVR, без FPU, без DMA и с крошечным стеком

В статье — как я боролся за каждый такт: Fixed‑Point арифметика, бинарное измерение углов, таблицы синусов, замена рекурсии на очередь задач. И почему 12 FPS на AVR — это повод для гордости.