C *

Добрый день, коллеги!

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

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

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

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

Если у вас кроссплатформенный проект на C или C++, то, как правило, вы не завязываетесь на одну систему сборки, а используете генератор сценариев для сборочных систем. Самый распространённый из них, CMake, недавно получил официальную интеграцию со статическим анализатором PVS-Studio для этих языков.

Yet another способ сверхбыстрого прототипирования из мелких модулей и печатных плат. Также, рассматривается вопрос вайбкодинга любых шрифтов на основе генерации из ttf для дисплея и вывода рисунка.

Одна из самых неприятных особенностей production-проблем заключается в том, что они почти никогда не происходят тогда, когда разработчик готов их исследовать.

Во время разработки всё работает. На тестовом стенде тоже всё выглядит нормально. Логи кажутся вполне достаточными, а диагностическая информация — продуманной и аккуратно организованной. Но затем в production внезапно появляется странная проблема: соединение иногда сбрасывается без видимой причины, один запрос из нескольких тысяч начинает вести себя иначе, сервер под высокой нагрузкой неожиданно входит в reconnect loop или где-то глубоко внутри системы начинает происходить что-то, что невозможно воспроизвести локально.

И почти всегда в этот момент выясняется одна и та же неприятная вещь: логов, которые уже есть в системе, недостаточно.

Именно здесь традиционное логирование начинает постепенно ломаться.

Большинство систем логирования до сих пор построены вокруг довольно простой идеи: заранее решить, какие сообщения должны писаться постоянно. Разработчик добавляет INFO, WARNING, DEBUG, иногда каналы или категории, после чего приложение отправляется в production с надеждой, что этих логов когда-нибудь хватит для диагностики.

Иногда действительно хватает.

Но реальные production-системы имеют неприятную привычку ломаться не там и не так, как ожидалось. Более того, проблемы часто возникают именно в тех участках кода, которые казались совершенно неинтересными во время разработки.

Первой реакцией обычно становится мысль: “давайте включим DEBUG logging”. На небольших проектах это ещё может работать вполне нормально. Однако в больших системах DEBUG-логи очень быстро превращаются в проблему сами по себе. Они начинают занимать гигабайты, полезная информация тонет в шуме, растёт нагрузка на диск, а иногда и само логирование начинает заметно влиять на производительность и тайминги приложения.

Вот, например, Milvius(DiskANN) рассчитан на вектора размерности до 32 768, но это приближенный поиск. Но как насчёт поиска точного?

В данной статье рассматривается работоспособность 1024 мерного индекса, хранилищем которого служит обычное B‑дерево (насколько вообще может быть обычным такое дерево). Используемый диск — вполне себе «железный» старый добрый WD Purple, оперативная память сознательно ограничена 8 Гб. Можно ли что‑то из этого выжать на рядовом десктопе за приемлемое время?

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

Для высоконагруженных систем, чтобы эффективно выделять и освобождать память под объекты без лишних вызовов malloc/free и потенциальных системных вызовов, используют паттерн пулов объектов.

«Задача абстракции — не быть расплывчатой, а создать новый семантический уровень, на котором можно достичь абсолютной точности», — Эдсгер Дейкстра

Взрывной рост количества промахов кэша

При определении топологии сети для обхода 500 коммутаторов нашей системе требовалось 37,5 миллисекунды. Вроде бы это не так медленно, если не учитывать количество промахов кэша: 8,5 миллиона. При 500 узлах это 17 тысяч промахов на узел.

Структура данных была фундаментально неподходящей для этой задачи.

Работа инструмента была простой: определение топологии сети при помощи обхода графа соединённых устройств. У каждого коммутатора было до 48 портов, а нам нужно было при помощи поиска в ширину найти все доступные устройства из начальной точки.

Реализация была как по учебнику — список смежности со стандартным BFS. В случае сети из 500 коммутаторов (в среднем по 12 соединений у каждого) статистика была такой: 8,5 миллиона промахов кэша на 500 узлов. Это 17 тысяч промахов кэша на узел!

Я переписал этот код, реализовав графовое представление, учитывающее кэш. Результаты: код стал в 3,75 раз быстрее, а количество промахов кэша уменьшилось в 7 раз.

В этой главе мы поговорим об эффективном описании и обходе графов.

Краткое примечание для читателей, не знающих о C3: это язык системного программирования, продолжающий традиции C. В статье приведена специфика C3, но все плюсы и минусы применимы к любому языку, в котором нужно выбирать типы для размеров и длин.

C3 переходит к использованию типов со знаком по умолчанию, но почему? Разве как минимум для размеров правильнее не использовать беззнаковые типы? Попытаемся ответить на этот вопрос.

Адаптация кода Рида-Соломона (РС) под контроллер esp32-s3. esp32-s3 имеет крайне интересный функционал поддержки работы с векторами. Задача - совместить кодирование РC с векторными возможностями этого микроконтроллера.

Компилятор и главный репозиторий: GitHub

Здесь я напишу о своём личном проекте — компиляторе к C-подобному языку. Я не являюсь профессиональным разработчиком, изучал эту тему почти самостоятельно и не читал никакие книги по написанию компиляторов (но читал по операционным системам).

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

OneOCR — это набор из двух динамических библиотек и одной модели ONNX для распознавания текста в приложениях Snipping Tool и Photos в Windows 11.

Я в Termux (планшет, смартфон) пытаюсь понять, как из нескольких строк на чистом Си рождается свободная и не зависимая личность - Нейрон.

Этот проект об искусственном интеллекте, который начался не с установки библиотек, а с чертежа в тетради. Здесь машинное обучение - это не абстрактный т тоермин, а физическая подстройка " Виртуальных резисторов ".

На нахожусь на периферии трёх миров :

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

Создатели ROS2 вынесли базовый функционал в C библиотеку  rcl (ROS Client Libraries). В теории, достаточно создать обертку на каком-либо языке программирования и можно пользоваться. Между тем, сторонних клиентских библиотек не так уж много. На мой взгляд, можно выделить следующие причины:

Рассмотрен подход к созданию управляемого "бэкдора", позволяющего подгружать функции без остановки и перезагрузки. С помощью манипуляций с линкер-скриптом и средств языка C создаются "точки расширения" в прошивке, позволяющие в будущем внедрять новые функциональные модули без пересборки и перезаписи всей программы. Такой подход может быть полезен при разработке отказоустойчивых систем для оптимизации жизненного цикла встроенного ПО, так как позволяет заложить гибкость при непредвиденных модификациях.

«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон

Разрыв в производительности

Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза.

Задача инструмента заключалась в парсинге строк логов в реальном времени, извлечении временных меток, уровней логов и сообщений из миллионов строк в секунду. Обработка миллиона строк логов в текущей реализации требовала 1,25 секунды — слишком долго для анализа в реальном времени.

Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем.

В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные.

Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими:

В 4,5 раза быстрее и в 7 раз меньше промахов кэша.

В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.

Полгода назад я начал портировать нейросеть EdgeFace-XS из ONNX в чистый C. Думал — граф небольшой, 1.77M параметров, что может пойти не так? Первый наивный порт выдал 24мс. ONNX Runtime — 3.9мс. В 6 раз медленнее. А потом началась оптимизация

«Блокировки — это goto конкурентного программирования», — Морис Херлихи

Проблема 60%

Наша система логгинга тратила 60% своего времени на ожидание снятия блокировок. Не на выполнение полезной работы, только на одно ожидание.

Восемь ядер, пытавшихся записывать сообщения логов, имели общий кольцевой буфер. Реализация была простой: буфер защищался мьютексом. При высокой нагрузке, когда все ядра записывали логи одновременно, профилировщик демонстрировал ужасный паттерн: 60% тактов CPU тратилось на операции с мьютексом.

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

«Можно ли улучшить ситуацию, отказавшись от блокировок?», — спросил меня мой менеджер во время ревью производительности.

Этот вопрос привёл к полной смене архитектуры...

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

В этом тексте я показал как настроить потоковую запись ADC семплов на микроконтроллере STM32.

ADC модуль это основа любого электронного измерения. Основа любого DMM. Всё что за корпусом микроконтроллера - это аналоговый мир. ADC это портал который позволяет аналоговым сигналам просачиваться в мир цифры.