(Продолжение. См. первую часть, где мы научились кодить на марковских алгорифмах "на бумажке").
Какие неприятности нас ждут?
Я уже сказал, что реализация НАМ в КТ - это задача со звёздочкой.
Что нам придётся героически преодолеть, и о чём понятно прямо на старте?
Руководство по разработке своей версии vsnprintf для целочисленных значений для увлекающихся osdev. Проходит стандартные тесты от gcc
В этой статье речь пойдёт не просто об очередном алгоритме, а о том, как можно обойти классический бинарный поиск. Казалось бы, что может быть эффективнее старого доброго деления массива пополам для нахождения значения в отсортированных данных? Однако можно пойти дальше. В этой статье будет рассказываться о самодельном алгоритме «SIMD Quad» - квадратичном поиске.
Идея возникла из необходимости быстро искать 16-битные целые числа в массивах размером до 4096 элементов — именно такие структуры лежат в основе популярного формата Roaring Bitmap. Вместо того чтобы на каждом шаге сравнивать искомый элемент только с одной серединой интервала, авторский алгоритм использует две ключевые аппаратные особенности современных процессоров. Во-первых, это SIMD-инструкции, позволяющие за раз сравнить до 16 элементов. Во-вторых, это распараллеливание работы с памятью, которое даёт возможность безболезненно делить массив не на две, а сразу на четыре части. Так родился гибрид, который сначала выполняет учетверённый поиск по блокам, а затем находит нужный элемент с помощью векторных инструкций. Давайте разберёмся, как это работает и почему такой подход действительно позволяет превзойти бинарный поиск.
Какие программы могут быть по-настоящему достойны хаба "ненормальное программирование"?
Конечно же, программы для нормальных марковских алгорифмов! (Далее - НАМ).
Но, будем честны перед собой: абстрактные машины - очень просты в реализации. Зачастую вызов состоит в том, чтобы сделать какую-нибудь эзотерическую версию, язык для машины на минималках, и затем ещё и минимизировать транслятор для него.
Поэтому поставим задачу со звёздочкой: научимся писать для НАМ в компайл-тайме С++!
Для начала, посмотрим: что такое НАМ и что на них вообще можно делать.
Приветствую читатель!
Для тех кто со мной впервые вот оглавление:
Код лежит тут
Подразумевается что читатель знаком с архитектурой аллокатора из части 3 и понимает алгоритм неявного списка свободных блоков который был освещен в части 1
Аллокатор работает стабильно, все тесты зеленые, включая тесты на стабильность. И следующим шагом логично бы реализовать перегрузки new и delete для abi, но вот незадача: там есть версии принимающие дополнительный аргумент, а именно выравнивание. Эту фичу я реализовать как раз забыл. В архитектуре которая рассматривается в предыдущей статье это оказалось простой, но интересной задачей. Ее мы и обсудим ниже.
Решение потребовало реализации функции mem_malloc_aligned которая выделит бОльший кусок памяти с учетом запрошенного выравнивания что бы мы там точно нашли правильно выровненный адрес.
Но что если адрес указателя из mem_malloc_aligned не совпадает с адресом указателя который вернул mem_malloc? Что делать в mem_free? Что делать в mem_realloc? Как мне работать с указателем перед которым не хедера?
Для начала я решил применить технику добавления смещения перед payload выровненного блока вместо хедера, смещения до payload изначального блока у которого есть хедер и футер.
Но как мне отличить offset от header? Я решил добавить magic number в хедер и футер увеличив тем самым размер оверхеда в 2 раза и раз уж от него считалось внутреннее выравнивание блоков памяти в аллокаторе и минимальный размер блока, то теперь минимальный размер блока стал 32 байта, а с оверхедом все 64. Теперь можно просто проверять magic number и если он не совпадает, то интерпретировать число на месте хедера как смещение до payload блока который вернул mem_malloc и далее получив на него указатель работать с блоком стандартным образом.
Ключевые особенности:
Расчёт опорной траектории на 5000 бит всего один раз.
Реактивный расчёт миллионов пикселей на аппаратном double.
При использовании чисел с плавающей запятой двойной точности (порядка 
) теория возмущений позволяет приблизиться к уровню 
- не дальше.
Революционный алгоритм Reference Reset to Zero.
Настоящий SSAA 2x2 для идеально сглаженного изображения.
Параллелизм OpenMP для высокоскоростного многопоточного рендеринга.
Синхронизация через DwmFlush для плавного вывода кадров.
Динамическое вращение палитры для создания классического эффекта.
https://github.com/Divetoxx/Mandelbrot-2#russian
Это Гитхаб с Mandelbrot_AVX2.exe и Mandelbrot_SSE3.exe
А тут полный код на языке С++ - main.cpp
Помните мою прошлую статью, где мы гоняли один и тот же современный альбом на четырёх типах лент через трёхголовочную Kenwood KX-1100G? Тот эксперимент показал: аналоговый звук жив, но характер цифрового мастера и точность калибровки деки часто влияют на результат сильнее, чем разница между Type I и Type IV.
За кадром осталась другая проблема. Современный стриминговый релиз — это −8…−10 LUFS integrated, True Peak на 0 dBFS и выше, плотный верх, широкий стереобас и brickwall-лимитирование. Записать такой файл на ленту «как есть» — получить грязный верх, нестабильный уровень, клиппинг на записи и бас, который «гуляет» между каналами из‑за crosstalk.
Вот уже более 20 лет проходит масштабная конференция разработчиков свободного и открытого ПО – FOSDEM. Для CodeScoring она примечательна тем, что с 2021 года на ней регулярно представлен тематический деврум "SBOMS and supply chains" посвященный составу программного обеспечения и цепочкам поставок.
Эта статья – адаптация доклада "LibreOffice and Collabora Online – how we managed to automate SBOM generation for a large legacy project", с которым Торстен Беренц выступил на конференции в 2026 году. Специально для вас мы перевели выступление и превратили его в статью, оригинал доклада на английском языке – по ссылке.
Главная ценность релиза — разработчик начинает с рабочей задачи, а не с выбора режима.
Каждый день есть задачи, которые хочется сделать быстро и чисто: разобраться с падающим тестом, поправить метод, доделать фичу. Но правильный путь не всегда понятен заранее: иногда нужна простая правка, иногда — исследование проекта, тесты, ревью или отладка.
Для этого в Veai 5.12 появился General Agent. Он принимает задачу в том виде, в каком разработчик обычно ее формулирует: неидеально, с сомнениями и неполным пониманием пути. Агент сам подбирает нужные действия и отдает результат, который уже можно проверить.
Попробовать Veai 5.12 · Что входит в релиз
В этом релизе мы собрали изменения, которые закрывают весь путь работы с агентом: от первого сообщения в чат до проверки результата.
Привет, Хабр! Меня зовут Владислав, я разрабатываю компиляторы в YADRO. В этой статье я расскажу вам про алиасинг памяти в C++: как он развивался, к чему пришел сейчас и что комитет по стандартизации языка думает делать с алиасингом в будущем. По пути я немного затрону алиасинг в других языках, рассмотрю связанные случаи undefined behavior, а также пропозалы C++, которые, как ожидалось, проблемы с алиасингом решат.
Когда эксперт впервые увидел, как моя машина ведёт себя в динамике, он сказал, что без курсов по двигателям и трансмиссиям меня к такому тренажёру подпускать нельзя. Он был прав. Меня позвали перенести с Unity на Unigine тренажёр гусеничной машины. К середине проекта я решил, что новую физику проще написать с нуля, и не написал в ней ни строки руками — весь код делал Claude Code. И да, там будет Патрик Суэйзи.
Я сделал это! Это огромный повод для гордости. Теперь программа работает по тем же математическим принципам, что и самые передовым фрактальным в мире!
Ключевые особенности:
Расчёт опорной траектории на 5000 бит всего один раз.
Реактивный расчёт миллионов пикселей на аппаратном double.
Революционный алгоритм Reference Reset to Zero.
Настоящий SSAA 8x8 для идеально сглаженного изображения без алиасинга.
Параллелизм OpenMP для высокоскоростного многопоточного рендеринга.
Есть полный код в С++ - main.cpp
Есть Гитхаб https://github.com/Divetoxx/Mandelbrot#russian с версии в виндовс Mandelbrot_windows_msse3.exe и Mandelbrot_windows_mavx2 и для Линукс Mandelbrot_linux_msse3 -msse3 и Mandelbrot_linux_mavx2
В третьей статье пойдет речь уже о готовом аллокаторе который вполне пригоден для распределения памяти
В стандарте C++20 было представлено множество нововведений, и одним из наиболее крупных и долгожданных в их числе являлись модули. Теперь, когда с тех пор минуло около шести лет, то воодушевление сменилось здоровым цинизмом. Так, авторы сайта Are We Modules Yet прогнозируют, что поддержка модулей во всех библиотеках будет обеспечена к 1 мая 2167 года, а на Reddit не проходит и двух недель, как возникает очередной тред на тему: «Ну что, ими уже можно пользоваться»? (спойлер: нет).
Моя собственная одиссея по работе с модулями началась с того, как я в очередной раз взялся переписывать мою воксельную игру. Насколько же слабо я представлял, во что ввязываюсь.
Тема конечных автоматов (КА) актуальна. Почти как тема реализации светофоров. Но вот, если серьезно, только отношение к ней разное. Время от времени появляются статьи типа «Конечные автоматы (FSM) – это ловушка для программиста» [1]. И здесь очень не хочется, чтобы складывалось превратное представление о некой «псевдо-математической» автоматной абстракции. Нужно оберегать народ от подобных суждений, которые ни на чем не основываются.
Не будем, в пику упомянутой статье, петь дифирамбы автоматам в очередной раз. Потому, как «сколько не говори халва, во рту сладко не станет». Но можно реализовать пример из статьи только с позиции другого взгляда на автоматы. Это больше убедит, чем пространные рассуждение в духе «свист-технологии» или той же многопоточности и конкурентности.
Пусть перед нами стоит задача реализовать светофор и при этом уже есть довольно интересное, если не сказать – оригинальное, решение, которое дает право автору статьи весьма критично высказываться в отношении автоматов. Само решение сводится к следующим шагам: 1) создается таблица, строки которой определяют цвет светофора и его время; 2) создается простая программка перебора строки, которая зажигает в прямом и переносном смыслах, реализуя управление светофором.
Про автоматы в существующем решении ни слова, ни полслова. Оно элементарно и создано, похоже, достаточно быстро, а вот создание стейт-машины, как утверждает автор, было бы долгим и упорным. Поскольку «упираться» автору программы, видимо, совсем не интересно, то попробуем это сделать за него мы.
Одна из главных автоматизаций в BIM – создание объектов. Разбираем создание объектов через Renga API шаг за шагом.
Как выкатить собственный движок JavaScript
Привет, Хаброжители! Мы подготовили для вас перевод статьи, в которой автор делится опытом создания собственного движка JavaScript с нуля.
Автор на языке Go с нуля создаёт простой движок JavaScript. В статье пошагово разобраны ключевые этапы: от лексического анализа и построения AST до реализации вычислителя и встроенных функций (print, fetch, JSON). Отличный материал, чтобы понять, как код на JS превращается в работающие инструкции.
Про C++ часто шутят, что любую вещь можно сделать пятью разными путями, четыре из которых компилируются, три работают, а два правильные, но один зависит от фазы луны. Часто такие шутки и идиомы откладываются в коллективной памяти сообщества какой именно из этих путей правильный в каждой конкретной ситуации.
Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr, ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые конструкции, которые в более поздних стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх.
Разработка игр тут не случайно, потому что игровой движок это обычно место, где абстракции встречаются с профилировщиком, и проигрывают ему чаще, чем хотелось бы. А легаси паттерны цветут и пахнут из-за чьих-то забытых в углу костылей, но большинство вещей вполне правильны, применяются и спасают от ошибок. Многое из этого спрашивают если не дословно, то хотя в паре слов, хорошие лиды на собесе, перед тем как позвать вас в команду, и просто взяв рандомо 5-6 пунктов можно составить впечатление, сталкивался ли новый человек с определенными проблемами.
Когда я собирал оглавление Game++, раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе.
Перед вами то, что могло бы стать половиной Game++, но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе.
Вероятно вам потребуется вспомнить некоторые правила вывода шаблонов, и что такое конструктор и деструктор, чем стек отличается от кучи, что у объекта есть время жизни, но это не точно. Я также намеренно убрал обработку краевых случаев и разные проверки из кода, которые в реальном коде заняли бы половину всего текста и утопили бы саму мысль в деталях. Паттерн механизма в моем случае важнее конкретной реализации, и почти каждая из них существует в десятке вариаций под разные компиляторы и стандарты.
Что будет, если написать HTTP/2-сервер на C++23 с нуля, собрать для него минимальный контейнер и выставить всё это в интернет? Я проверил проект на реальном трафике, усилил защиту бинарника и контейнера, столкнулся с ограничениями Cloudflare, bunny.net и Cloud Run, а заодно поймал утечку памяти в OpenSSL. Получился практический разбор того, где заканчивается учебный эксперимент и начинается эксплуатация системного кода.
Каждый, кто осваивает Arduino, проходит одни и те же этапы.
Сначала ты мигаешь светодиодом. Потом подключаешь датчик температуры — и вот уже температура выводится в монитор порта. Потом сервопривод — и какая-то пластиковая штуковина начинает смешно поворачиваться туда-сюда.
Потом появляется идея сделать систему автополива для цветов (которая в итоге их зальёт). Или мобильного робота, который будет «приносить тапочки». Правда, через месяц робот будет пылиться на полке, а датчики с него переедут в следующий проект :).
Дальше — закономерный этап: хочется управлять всем этим через интернет или со смартфона по каналу Bluetooth. Использовать Wi-Fi модули, заменить Arduino на ESP8266 или ESP32. Поднял сервер, написал пару кнопок — работает.
И если все это тебя зацепило, то возникает вопрос: а что дальше?
Я тоже прошёл эти этапы. И когда задумался, куда двигаться дальше, обратил взор на ИИ (Искусственный Интеллект). Не на тот, что «Skynet уничтожит человечество», а на самый простой — умение робота видеть знак «Стоп» и отличать его от пустой стены.
Воодушевленный идеей, начал собирать информацию про ИИ на микроконтроллерах — и быстро понял, что обычный Arduino Uno с его 2 КБ оперативной памяти (RAM) и 16 МГц для нейросетей решительно не подходит. Модель с распознаванием изображения туда не запихнуть. Даже самую простую.
Примечание
Кстати, это направление даже имеет своё название — TinyML (машинное обучение для микроконтроллеров с ограниченными ресурсами). Минимальные требования для простых задач (классификация звуков или данных с датчиков) — тактовая частота от 32 МГц, RAM от 32 КБ, Flash от 128 КБ. У Uno даже близко нет.
