В Deckhouse Prom++ мы переписали ядро хранения и обработки горячих данных на C++, при этом вся оркестрация и периферия остались в Prometheus на Go, что позволило сохранить полную совместимость с Prometheus. Для частых вызовов кода C++ мы использовали механизм CGo, однако первые тесты показали, что производительность CPU практически не улучшилась из-за его медлительности. В итоге мы переписали CGo, создав собственный механизм вызова.

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

UTF-8 валидация — одна из базовых операций при работе с текстом, которая выполняется миллионы раз в секунду в современных приложениях. Стандартная реализация в Go, хоть и корректная, далека от оптимальной по производительности. В этой статье расскажу, как мне удалось ускорить валидацию UTF-8 в 10 раз, используя SIMD‑инструкции ARM NEON и алгоритм из статьи «Validating UTF-8 In Less Than One Instruction Per Byte» Джона Кейзера и Дэниела Лемира.

Как вычислить экспоненциальную функцию быстро и с минимальной погрешностью? Пишем векторизованный код.

Представлен цифровой фильтр без использования явной аппаратной или программной операции умножения, выполненный на основе двоичных сдвигов. Имеет дискретный ряд АЧХ, ФЧХ, при этом, эффективно реализуется на простейших контроллерах.

Почему при сложениии одинаковых чисел в разном порядке получаются разные результаты?
Как мининмизировать ошибки округления или избавиться от них совсем?

Моим первым языком программирования был ActionScript. Написание кода для Macromedia Flash максимально далеко от голого железа, и эта специфика работы глубоко засела в моём сознании. В результате меня интересовали преимущественно высокоуровневые языки для веб-программирования. Низкоуровневые же казались непостижимыми. Со временем я постепенно из разных источников узнавал о них всё больше, но это моё убеждение оставалось прежним. Низкоуровневые языки пугают, и машинный код подтверждал это наглядно. Когда я обращался к Google с запросом «понятный машинный код», то результат выдачи чаще представлял нечто пугающее и отталкивающее, нежели полезное для обучения.

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

Машинный код вовсе не страшен. Если вы можете обеспечить, чтобы документ JSON соответствовал схеме JSON, то без проблем сможете писать машинный код.

QapDSL — декларативное описание AST и парсеров для C++

QapDSL — это специализированный язык (DSL), который позволяет описывать абстрактные синтаксические деревья (AST) и правила их разбора для языков программирования, прежде всего C++. Такая формализация помогает автоматизировать построение парсеров, генерацию кода, анализ исходников и даже рефакторинг.

Зачем нужен QapDSL?

• Компактно и наглядно описывать структуру и грамматику языка.
• Автоматически генерировать C++-структуры, парсеры, сериализаторы и визиторы.
• Ускорять эксперименты с языками, создавая прототипы компиляторов и анализаторов.
• Упрощать анализ и рефакторинг сложных языков, в т.ч. C++.

Пример QapDSL-описания

Рассмотрим, как описывается объявление класса C++ на QapDSL:

t_class{
  string keyword;
  t_sep sep0;
  string name;
  t_sep sep1;
  TAutoPtr<t_parents> parents;
  t_sep sep2;
  TAutoPtr<t_class_body> body;
  t_sep sep3;
  {
    M+=go_any_str_from_vec(keyword,split("struct,class,union",","));
    O+=go_auto(sep0);
    M+=go_str<t_name>(name);
    O+=go_auto(sep1);
    O+=go_auto(parents);
    O+=go_auto(sep2);
    O+=go_auto(body);
    O+=go_auto(sep3);
    M+=go_const(";");
  }
}

С 10 по 14 апреля 2025 года прошел первый онлайн RISC-V хакатон, организованный Ассоциацией RISC-V. Участникам на выбор давались 2 задачи. Одна задача от Codasip -доработать программу и кастомный процессор для вычисления LLM трансформера. Другая от Andes - улучшить вычисление функции softmax. Для демонстрации работы векторного расширения RISC-V задача с softmax мне показалась более подходящей.

Интересно было изучить, как в процессорах реализуется вычисление нелинейных функций, как например экспоненциальная функция, нужная для softmax.

Помните, как долго выполняется сложение на бумаге?

¹¹ ¹
6876
+ 3406
------
10282

Начиная с единиц, мы складываем 6 + 6 = 12, записываем 2 и переносим 1. Затем пошагово двигаемся влево, пока складываемые разряды не закончатся.

При реализации сложения больших чисел (например, от 2⁶⁴ и выше) обычно пишут код, похожий на этот алгоритм. Любопытно здесь то, что существует простой трюк, позволяющий существенно ускорить этот процесс на современных CPU.

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

Дело, разумеется, в переносе. Мы не можем точно знать, каким будет текущий разряд числа, пока не выполним все сложения справа от этого разряда.

Предупреждение: в этом посте активно используется язык ассемблера x86_64, в котором я ни в коем случае не являюсь специалистом. Для написания статьи мне пришлось изучать приличный объём материалов, и, возможно (почти наверняка), в ней есть ошибки.

Нас ждёт мозговыносящая смесь 64/32-битного ассемблера и старого-доброго C++. Мы сделаем собственную реализацию... Волокон (fibers) без вызова Win API и звонков в службу спасения.

В этой статье разбирается решение задачи «Гистограммы» с контеста Route 256 от Ozon с помощью SIMD.

Условие задачи

Гистограммой является массив, каждый элемент которого указывает высоту столбика на соответствующей позиции. Две гистограммы считаются совпадающими, если при совмещении одной гистограммы с другой гистограммой, повёрнутой на угол 180°, получается ровный прямоугольник без наложений и пропусков.

В этой части нас ждёт погружение в один из способов организации мультипоточности на базе единственного ядра процессора. Мы научимся принудительно переключать выполнение между полностью зацикленными участками кода, ничего не "знающими" о каком-то другом коде, конкурирующем за процессорное внимание. По ходу повествования будут даны все необходимые пояснения и читателю не придётся обращаться к другим источникам, кроме первой части статьи.

В первой части статьи мы рассмотрели, как можно вручную ускорить Go-код с помощью векторизации и SIMD-инструкций, реализованных через Go-ассемблер. Написали простую, но показательно быструю реализацию sliceContains и увидели, что даже базовая векторизация может дать ускорение в 10–14 раз по сравнению со стандартной реализацией.

Во второй части статьи погрузились в практическое применение SIMD в Go-ассемблере, реализовали функцию SliceContainsV1 и изучили, как с помощью VADD, VDUP и других инструкций можно добиться 10–14-кратного ускорения простых задач.

Но возможности оптимизации Go-программ на этом не заканчиваются. В этой части мы пойдём дальше: рассмотрим другие техники низкоуровневой оптимизации — от использования C-кода и альтернативных компиляторов с поддержкой векторизации до работы с аппаратными транзакциями памяти на Intel. Поговорим о том, как внедрять ассемблер в продакшен-код, не боясь за его поддержку, и как обойти ограничения стандартного Go-компилятора.

Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества, веду телеграм-канал и youtube-канал. Если вы уже знакомы с базовыми техниками векторизации, эта часть поможет глубже понять, как устроены продвинутые способы ускорения Go-кода и на что стоит обратить внимание при работе с архитектурно-зависимыми оптимизациями.

Ускорить простые задачи, вроде поиска в массиве и сравнения слайсов, поможет мощь SIMD. Эти векторные инструкции, которые обрабатывают десятки байт данных за один такт процессора, отличная замена традиционным циклам. Во второй части статьи мы погружаемся глубже в практическое применение SIMD в Go-ассемблере, реализуем функцию SliceContainsV1 и изучим, как с помощью VADD, VDUP и других инструкций можно добиться 10–14-кратного ускорения простых задач.

Из этой статьи вы узнаете:

• Как устроено сравнение массивов с помощью SIMD-инструкций;

• Почему векторизация быстрее бинарного поиска;

• Как правильно работать с регистрами, фреймами и указателями в Go-ассемблере;

• Что нужно учесть при переносимости и поддержке низкоуровневого кода;

• Когда ассемблер оправдан и безопасен в реальных проектах на Go.

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

В первой части статьи мы разобрали саму идею ускорения кода на Go с помощью ассемблера. А в этой разберём её практическое применение.

Даже в 2025 году, когда вокруг нейросети, автогенерация кода и IDE с предиктивным интеллектом, работа с редкими микроконтроллерами всё ещё может обернуться настоящим хардкором. Особенно, если речь идёт о «слепой» отладке без отладчика, когда в арсенале только прошивка, HEX-файл и пара байтов на выводе. В этой статье — личный опыт, много хардкора, дизассемблирование вручную и поиск глюка в 2 КБ бинаря.

Когда говорят «отладка», в 2025 году чаще всего имеют в виду жмяк на F5 в Visual Studio Code или лог с CI/CD. Но в embedded-мире, особенно если ты копаешься в системах с 8-битным контроллером 2006 года выпуска, это слово может означать кое-что пострашнее. Например — «прошивка вылетает на 4-й секунде, данных в UART нет, отладочного интерфейса нет, документации почти нет, а заказчик просит сделать "как раньше работало"». И вот тут начинается старый добрый reverse engineering.

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

Ассемблер может показаться сложным и пугающим, но он открывает большие возможности для работы с низкоуровневыми оптимизациями. Готовы разобраться, как это работает? Тогда погнали!

Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества.

Одним днём я читал отчёты по TI из различных источников. В одном из таких отчётов упоминался некий алгоритм для распаковки вредоносного ПО, под названием PolyUnpack. Мне стало интересно, и я решил изучить данную тему. Оказалось, что в Интернете очень мало информации по данному алгоритму. Из интересного я нашёл статью, в которой впервые был описан алгоритм и чью-то курсовую работу.

Я решил написать свою реализацию данного алгоритма, так как часто приходится иметь дело с запакованным ВПО. В этой статье я расскажу, в чём заключается алгоритм, как я его реализовал, с какими проблемами я столкнулся и какие есть альтернативы для распаковки вредоносов. В конце я оставил ссылку на GitHub.

Вторая часть уже здесь.

В первой части мы:

• посмотрим, как работать с памятью и регистрами 8086

• узнаем, как написать простую программу на ассемблере прямо в отладчике

• изучим работу механизма прерываний и сделаем демонстрационный пример

Статья рассчитана на тех, кто имеет начальный опыт программирования, но хочет понять основы низкоуровневого программирования и многозадачности.

Примеры в бинарном виде доступны по ссылке

Недавняя публикация о векторном расширении RISC-V архитектуры, подтолкнула меня к мысли написать небольшую заметку об использовании данного расширения в задаче, имеющей практическое применение. После появления векторного расширения, в сети начали публиковаться статьи о применении RISC-V ядер с данным расширением в задачах, ранее в которых безальтернативно использовались только процессоры ЦОС. В данной статье рассматривается тест, в котором используется алгоритм декодирования Витерби - задача, требующая значительных вычислительных ресурсов.